Alibaba reported a peak of 583000 order creations per second during Singles' Day in 2020. A system that idles at a small fraction of that for 364 days cannot be validated by ordinary load testing. What does an organisation have to build to make that peak survivable, and where would copying it be a mistake?

The situation they were in

A retail event with a known date, a known start minute, and a peak three or four orders of magnitude above baseline. The load is not a surprise, which changes everything about how it is engineered. An unpredictable peak is handled with headroom and shedding. A predictable one can be rehearsed, and rehearsal is the only way to find the failures that appear only at peak.

The defining constraint is that failures at that scale are not the failures seen at 1% of it. Connection pool limits, identifier generation, cache stampedes on the same hot item, database write hot spots on a single popular product row, and the behaviour of every retry policy in the fleet under simultaneous pressure are all peak-only phenomena.

What that forces you to build

• Full-path rehearsal against production, with marked traffic. Synthetic orders are tagged so that every service can route their writes to shadow tables rather than real ones, then the same code, the same caches and the same database instances take the real peak shape. Alibaba has described this style of full-link pressure testing publicly, and the important part is not the tooling: it is that the rehearsal exercises production, because a staging environment at 1% scale cannot reproduce the failure modes you are looking for.
• Isolation by traffic class. Flash-sale traffic gets its own capacity so that when it saturates, ordinary browsing and payment flows do not. This is the cell idea applied by workload rather than by tenant: a blast radius drawn deliberately around the traffic most likely to overload.
• Pre-provisioning rather than reactive scaling. Autoscaling reacts in minutes; the peak arrives in seconds. Capacity must be standing before the clock strikes, which means paying for it idle.
• A degradation ladder decided in advance. Recommendations off, then personalisation off, then non-essential writes queued, with the order agreed by the business before the event rather than by an engineer at peak.
• Inventory as the hard core. Everything else can be approximate; overselling cannot. That usually means a small, heavily optimised path with its own capacity, often pre-allocating stock into per-shard buckets so the hot row is not a single row.

What it cost them

Standing capacity for an event that happens once a year, an engineering practice that consumes months, and the operational risk of running load tests against production. These are enormous costs justified by a single day's revenue, which is the fact that makes the whole approach rational.

When copying this is the wrong answer

Almost everywhere. Three conditions have to hold before any of this is worth it:

1. The peak is scheduled. If traffic surges unpredictably, rehearsal has no date to rehearse for, and the money goes into shedding and headroom instead.
2. The peak-to-baseline ratio is extreme. At 3x, buy headroom. At 100x, headroom is unaffordable and rehearsal is the only option.
3. The event's revenue justifies dedicated engineering for months. For most businesses it does not, and the same effort spent on a shedding path and a degradation ladder protects far more of the year.

The transferable lesson is not the architecture; it is that a system's behaviour at peak is unknown until it has been at peak. A quarterly game day that drives one service to saturation in production teaches a small team more than any amount of staging load testing, and costs a fraction of a rehearsal programme.