Every system works well with one user. The problem starts with a thousand at the same time.
Most teams discover the limit of their own system in the worst way possible: in production, during the peak, with the customer watching. The campaign explodes, the article goes viral, the tax deadline arrives, and what seemed robust collapses because no one ever measured how much it could last.
Load testing exists to reverse this order. Instead of the user finding the limit by accident, you find it on purpose, in a controlled environment, before it hurts.
What actually is a load test
Load testing is subjecting the system to an increasing volume of requests or simultaneous users to measure how it behaves under demand. The question he answers is not “does it work?”, but rather “does it work with how many?”.
Notice the difference. A functional test verifies that the functionality is correct. A load test checks that it remains correct and fast when many people use it at the same time. These are different questions, and the second only appears in scale.
You simulate a realistic number of users performing real actions, login, search, checkout, and observe response time, error rate, and resource usage as load increases. The result is a portrait of how the system degrades.
The difference between load, stress and performance
It is worth separating terms that are often confused, because each one answers a different question.
Load testing measures behavior under expected and increasing demand, how many simultaneous users the system supports with acceptable quality. Stress testing goes overboard, on purpose, to see how the system breaks down and recovers. Performance testing, in a broad sense, measures response times and efficiency, often under some load.
Cargo responds "can it hold up as expected?" Stress answers "what happens in the extreme?". Keeping them separate in your head prevents wrong conclusions from the wrong test.
Why this is a business decision, not just a technical one
It's tempting to treat cargo as an engineering detail. It's a mistake. Your system's capacity limit is the limit of how many customers you can serve at the same time, and that's pure business.
Imagine a public scheduling service that opens vacancies on a specific day. The entire eligible population arrives within the same time window. If no one has tested the load, the system crashes just when it matters most, and the failure becomes headline news. The cost is not technical; is institutionally trusted.
The same goes for a startup preparing a launch. Investing in media to bring a spike in traffic and having the website offline at the time of the peak is burning money twice: the media and the reputation.
What to measure, and what the metrics hide
The obvious metrics are response time and error rate. They matter, but they only tell part of the story.
Average weather is deceiving. A good average can hide a fraction of users with terrible experience. That's why I look at percentiles, the time the worst 5% or 1% experience, rather than averages. That's where the real frustration lies.
Also, look at the resources behind: CPU usage, memory, bank connections, request queue. Often the bottleneck is not the application server, but the database or a poorly sized connection pool. The load test not only shows that it has degraded; well instrumented, shows where.
The most common errors
The first mistake is testing in an environment that doesn't look like production. Running loads on a tiny machine or with an empty bank generates beautiful and useless numbers. The test environment must be representative, and the data must be similar in volume to the real one.
The second is to simulate unreal users. A thousand identical requests on the same endpoint do not reflect human behavior. Real users browse, think, repeat actions, abandon. A payload scenario reproduces this pattern, not a uniform robot.
The third, and most common, is to test once, before launch, and never again. Capacity is not static. Each new feature, each new query to the bank, can change the limit. Non-recurring load testing has a short validity.
When to start worrying
Not every system needs load testing from day one. An internal product used by ten people does not justify the effort. The right question is about spike exposure.
If your system has predictable moments of concentrated demand, campaigns, deadlines, launches, seasonality, or rapid base growth, load testing is no longer optional. And the best time for the first measurement is before the first big spike, not after it.
The mindset shift I advocate is simple: capability is a requirement, not a surprise. Knowing your system's ceiling is just as important as knowing whether it does what it promises. One tells you it works; the other tells you how long it will continue to work when success arrives.
If your organization has a peak event on the horizon and no one knows for sure whether the system can handle it, this is the type of risk worth addressing beforehand, not during. I have other texts on the blog about performance, scalability and reliability that speak to this one.