Flash Sale Architecture: Surviving Campaign Day
Campaign day architecture: the waiting room, stock reservation design, the hot product problem, absorbing traffic spikes and the campaign runbook — the whole series in one scenario.
Why is a flash sale a different problem, not just a bigger peak?
Because traffic does not merely grow — it changes shape: tens of thousands of users arrive in the same second, at the same few products, with the same buy button. The assumptions of normal-day architecture — dispersed access, cacheable variety, independent transactions — invert completely: one hot record, zero cache tolerance, lock contention. This closing article unites every pattern of the series in one scenario: surviving campaign day.
Layer 1: Shaping traffic at the gate — the waiting room
The first truth of a flash sale is acceptance: if the system's transaction capacity is X per second and 50X arrives, the excess is either organized at the gate or everything collapses for everyone inside. The waiting room is the industry standard for that organization: visitors to the campaign page enter a light, static queue (at the CDN/edge — never touching the application); fair ordering (randomly assigned position + FIFO) is preserved; users are released into the real site at a controlled rate (N per second), and every entry is validated by a short-lived signed token — queue-jumping via shared URLs must be impossible. Experience design matters: showing queue position and estimated time prevents the refresh storm (F5) born of uncertainty — the very load the waiting room exists to solve.
Layer 2: The hot product problem — stock and lock design
All admitted traffic hits a few rows: the campaign product's stock record. The classic read-check-write pattern dies here in two ways: queuing under pessimistic locks, conflict storms under optimistic ones. The working design is layered: stock moves to Redis as an atomic counter (decrement-and-check in one step; a request that drives it negative gets an instant 'sold out' — without ever reaching the database); a successful decrement becomes a reservation (with a TTL: unfinished payments release stock automatically); the durable record is written through an async queue (the order line, under the idempotent consumer + outbox discipline of our queue article). Overselling tolerance is a business decision: strict zero with atomic counters; small tolerance + compensation (rare cancel/apology) buys higher throughput — the choice is made deliberately and written down. Sharded counters are the tool of the far extreme where even one key is a bottleneck.
Layer 3: Making the page cheap — every request must be absorbed
Unlike a normal product page, the campaign page is fully staticized: content on the CDN, prices and images under versioned URLs, and the counter/stock status fed from a single small endpoint with a short TTL. Personalization, recommendations, everything non-realtime is stripped from the campaign template — the harshest application of the absorption principle from our caching article: a request reaches the application only if it must. The same discipline applies to the API: the mobile campaign screen feeds from one bulk endpoint; 'one call per widget' is suicide on campaign day.
Layer 4: The series' patterns on stage
Pattern (article) | Its role on campaign day |
|---|---|
Capacity math (1) | Pre-scaling: expected peak × margin; autoscaling is not trusted for the opening |
Caching + stampede (2) | Page absorption; cache pre-warming for keys that fill at once at launch |
Data layer (3) | Reads on replicas; hot counters in Redis; order writes partitioned |
Queue + backpressure (4) | The order line async; queue depth is the campaign's pulse |
Rate limit + shedding (5) | Bots/abuse at the gate; ornaments shed first, payment protected |
Resilience (6) | Breaker on the payment provider; dependencies bulkheaded |
Saga + consistency (9) | Reserve→charge→order flow compensated; state transparent |
Operations: a campaign is an engineering event
Operations are designed as much as architecture. Before: production-like load tests (with the campaign scenario — not the normal traffic profile), pre-scaling and cache pre-warm plans, a 'campaign mode' behind feature flags (heavy features off), a written runbook and role assignments. During: a single-screen campaign dashboard (queue depth, stock counter, error rate, p99, DLQ), a freeze window (no deployments during campaign hours) and a war room with clear decision authority. After: reconciliation (reservation-payment-stock consistency), release of expired reservations, and a metrics-driven retrospective — the next campaign's capacity math comes from this data.
Business impact: campaign day is architecture's balance sheet
A flash sale is the moment software architecture converts most directly to revenue: a system that stays up turns the campaign budget into sales; a system that collapses spends the same budget advertising for competitors — under a 'site crashed' hashtag. The sum of the disciplines built across this series is preparation for exactly this day: absorption rates, capacity math, backpressure, controlled shrinkage and flow integrity. On campaign morning only one question should remain: 'which runbook step are we on?' — never 'what do we do now?'.
Frequently asked questions
Waiting room: managed service or in-house?
CDN providers' managed waiting rooms are the fast, safe start for most scenarios; when very specific fairness/priority rules are needed (loyalty-segment priority, say), custom edge development is worth evaluating.
What if Redis fails under the stock counter?
The scenario must be written: persistence (AOF) + replica failover are the base; against residual loss, a 'halt sales + rebuild from database' procedure and recount from reservation records stay ready.
Why isn't autoscaling enough for campaigns?
On a vertical spike, new capacity's startup time (minutes) cannot catch the first wave. Known peaks are scaled in advance; autoscaling manages intraday variation, not the opening.
How is bot/scalper defense structured?
Layered: waiting room tokens + device/behavior analysis + per-account/address quantity limits + verification on suspicious patterns. No single tool suffices; the goal is not zero bots but protecting real customers' chances.
Campaign day checklist
Campaign-scenario load test done; pre-scaling plan approved
Waiting room in place; token validation and fair ordering tested
Stock on atomic counters; reservation TTL and release flow working
Campaign page staticized; cache pre-warm planned
Campaign-mode flags ready; freeze window announced
Single-screen dashboard + runbook + war room roles defined
Post-campaign reconciliation and retrospective scheduled
SSH Yazılım builds campaign-day architecture end to end — from waiting room to stock design to the runbook. Let us turn your next big day into a win together.