Key takeaways
- Build the load model from last peak’s real traffic. The mix and timing of journeys matter more than the headline request rate.
- Test past the forecast, because forecasts tend to be wrong in the direction that hurts.
- Third-party dependencies — payments, tax, search, delivery quotes — often fail first. Agree their limits and test against them.
- Decide in advance what degrades gracefully and what gets switched off, and test the switches.
- A change freeze only helps if the release before it was the most tested of the year.
Start from real traffic, not a round number
A load test that sends a million requests to the home page proves very little. Peak traffic has a shape: more browsing and search, sharp spikes when a promotion goes live, a checkout funnel under pressure, and a lot of bots. Build the model from last peak’s analytics and logs — the journeys, their mix and their timing — then scale it to this year’s forecast.
- Journey mix: the share of browse, search, basket and checkout, and how it shifts when a promotion starts.
- Spikes, not averages: the minute a campaign email lands matters more than the hourly mean.
- Realistic data: catalogue size, basket sizes and promotion rules that match production.
Test past the forecast
Test at the forecast to prove you can serve it, then keep going until something gives, so you know where the edge is and what fails first. Run a long soak test as well: memory leaks and exhausted connection pools show up after hours, not minutes.
The dependencies you do not own
Payment providers, tax and address services, search, recommendations and delivery-slot APIs are often the first things to slow down, and you cannot scale them yourself. For each one, know its rate limits, agree peak volumes with the provider in advance, test against a realistic stub where you cannot test against the real thing, and decide what happens when it is slow.
Decide what to switch off before it breaks
| Feature | Under pressure |
|---|---|
| Recommendations | Fall back to a static list of bestsellers |
| Live stock counts | Show in stock or low stock from a cached view |
| Search suggestions | Switch off, and keep search itself |
| Personalised banners | Serve the default campaign |
Each of these should be a switch someone can flip in seconds and that has been tested before peak — not a code change made under pressure on the day.
The freeze and the war room
- Make the last release before the freeze the most tested of the year, because you will live with it through peak.
- Write down who can approve an emergency change, and how it is tested at speed.
- Rehearse the war room a few weeks out: the same people, dashboards and runbooks you will use on the day.
- Watch what customers see, with synthetic journeys through checkout, not only server metrics.