Load testing a checkout for Black Friday

Peak season does not break storefronts. It breaks checkouts, inventory reservations and whatever downstream system was never designed for concurrency. Load testing the homepage tells you almost nothing useful.

Test the journey, not the endpoint

Model a real basket: browse, search, add to cart, apply a promotion, check out, pay. Run it at three times last year’s peak, with the same ratio of guest to logged-in users, and with your real payment provider in sandbox.

Break things on purpose

Game days are worth more than raw load numbers. Kill the search cluster mid-test. Add 500ms of latency to the ERP. Return a 500 from the payment provider on one in twenty calls. What you are testing is whether checkout degrades gracefully or takes the site with it.

Protections that actually help

1. Queue and throttle in front of checkout rather than letting it collapse
2. Circuit breakers on every downstream call, with a defined fallback
3. Cart-level stock reservation with a timeout, so promotions do not oversell
4. Static fallbacks for category and product pages when personalisation is unavailable
5. Autoscaling with a floor high enough to absorb the first spike

Have this ready before the window

A frozen release branch, a rollback that has been rehearsed, dashboards on one screen, an on-call rota with names on it, and a decision-maker who can approve turning a feature off. Most peak incidents are made worse by nobody being allowed to decide anything.