Every autumn the same conversation happens in the same meeting room. Someone asks whether the platform will hold on Black Friday, and someone else answers that it should be fine. This is how you replace should be fine with a number.
Build the load model from your own data, not from a guess
Most load tests fail before they run, because the traffic they generate looks nothing like real traffic. The starting point is not a tool. It is last year’s data, at minute resolution.
Pull the previous peak day from your analytics and your access logs, and build a table of requests per minute broken down by journey: home and campaign landing, category browse, product detail, search, add to cart, checkout start, payment, order confirmation. You want the shape of the day, the peak minute, and the ratio between journeys at that peak minute. The ratio matters more than the absolute number, because the ratio is what determines which service falls over first.
Then apply growth. If marketing has bought forty percent more traffic and the business has opened two new markets, model that. We test at three times the previous peak hour as a default, not because we expect three times the traffic, but because the point of the exercise is to find where the system breaks, and a system that only just survives its expected load has no headroom for the thing nobody predicted.
Test the environment you will actually run on
A load test against a scaled down staging environment tells you almost nothing. Connection pools, cache sizes, database instance classes and rate limits are all absolute numbers, and they behave differently at different scales. Either test against production shaped infrastructure, or test against production in a low traffic window with a plan to stop.
Data shape matters as much as infrastructure shape. A catalogue of two hundred test products will sit entirely in cache and tell you your cache hit rate is ninety nine percent. Your real catalogue of three hundred thousand will not.
Break things on purpose
The interesting failures are almost never raw throughput. In our experience the same five failures come up again and again.
| Failure | What it looks like | Usual fix |
|---|---|---|
| Connection pool exhaustion | Latency climbs smoothly then falls off a cliff, with no CPU pressure anywhere | Right size the pool against instance count, add a queue with a bounded wait |
| Cache stampede | A popular key expires and several hundred requests all recompute it at once | Request coalescing, jittered expiry, serve stale while revalidating |
| Unbounded retries | One slow dependency turns into a self inflicted denial of service within seconds | Retry budgets, exponential backoff with jitter, circuit breakers |
| Missing back pressure | Order writes accepted faster than they can be processed, queue grows without limit | Queue based load levelling with a bounded queue and a shed strategy |
| Cold start under scale out | Autoscaling adds instances that take ninety seconds to warm, so scaling makes it worse | Warm floor sized to peak minus a margin, pre warmed connections and caches |
Table. The five failures we find most often when load testing commerce platforms for the first time.
The four numbers that decide whether you are ready
At the end of a test cycle, four numbers tell you whether to sleep in November.
- Peak sustained order rate. Orders per minute the system completes end to end, including the write to the ERP, for thirty minutes without degradation. Not a burst. Sustained.
- Checkout latency at peak, p99. Not the median. The median is fine on every system that has ever failed on Black Friday. Watch the tail.
- Error budget burn under load. What percentage of requests fail at target load, and whether the failures are graceful. A cached category page served slightly stale is not a failure. A five hundred on add to cart is.
- Time to recover. Kill a dependency mid test and measure how long the system takes to return to normal once it comes back. If it does not recover without a restart, you do not have a resilient system, you have a system that has not failed yet.
Then rehearse the day itself
The technical work is only half of it. Before the peak we agree a code freeze window, confirm who is on call and what their escalation path is, check that everyone can actually access the dashboards and the bridge, and run a tabletop exercise on two or three plausible incidents. The first time somebody tries to find the runbook should not be during the incident.
We also agree in advance what we will turn off. Personalisation, recommendations, live chat and non essential third party scripts all have a documented kill switch, and the criteria for using it are written down before the day so nobody has to make that call under pressure at nine at night.
What good looks like
The last client we did this for came into peak with traffic 2.6 times higher than the previous year. There were no incidents, no queue and no manual intervention. The interesting part is not that number. It is that in September we had found four things that would have taken them down, and none of them were capacity.
Next step
Put this in front of your own numbers
We run a fixed scope technical assessment of your storefront, checkout and integration layer, then hand back a prioritised plan with effort and expected impact.