Problem Statement & Context
What a flash sale system is and why it is challenging
Problem Statement & Context
A flash sale platform runs time-boxed, inventory-limited promotions that attract millions of shoppers within minutes. The goal is to maximize conversion while guaranteeing fairness, preventing oversell, and keeping checkout reliable under extreme load spikes.
What makes flash sales unique
They create burst traffic (100K–300K QPS in the first minute), bot/scalper activity, and intense inventory contention at a scale normal commerce paths never see — all against a tiny, fixed pool of inventory.
The journeys
- Buyer: view upcoming deal + window → join waiting room at start → receive queue token + enter purchase window → select quantity + checkout → confirmation or waitlist.
- Operations: configure sale (SKU, price, allocation, window) → pre-warm caches + set rate limits → monitor queue depth/conversion/errors → adjust allocations or pause.
The load-bearing idea: a queue converts an unservable flood into a servable stream
The defining problem is that you cannot let a million users hit checkout simultaneously — the inventory and payment services would melt, and you would oversell. The architecture's answer is a waiting room / queue in front of the correctness-critical path: it admits users at exactly the rate the inventory and checkout services can absorb, turning an instantaneous flood into a controlled, steady stream. Everything else follows from this — atomic inventory reservation guarantees no oversell within that admitted stream, per-account rate limits and anti-bot controls preserve fairness in the queue, and regional inventory allocation localizes the contention. Gate the flood at the front, guarantee correctness on the trickle that gets through.
Scale anchors
100K–300K QPS at start; 1M+ concurrent queue sessions; sale window 5–30 min; oversell rate < 0.01%. These drive the queue, the atomic-reservation design, and aggressive pre-warming.
Key Highlights
- •A flash sale platform runs time-boxed inventory-limited promotions attracting millions in minutes — maximize conversion while guaranteeing fairness, preventing oversell, keeping checkout reliable under extreme spikes; burst traffic 100K-300K QPS in the first minute against a tiny fixed inventory pool
- •Journeys: buyer (view deal -> join waiting room at start -> queue token + purchase window -> select quantity + checkout -> confirmation/waitlist), ops (configure SKU/price/allocation/window -> pre-warm + rate limits -> monitor queue depth/conversion/errors -> adjust/pause)
- •The load-bearing idea: you CANNOT let a million users hit checkout at once (inventory + payment would melt + you'd oversell) — the answer is a WAITING ROOM / QUEUE in front of the correctness-critical path that admits users at exactly the rate inventory + checkout can absorb
- •It converts an instantaneous flood into a controlled steady stream; everything follows — atomic reservation guarantees no oversell WITHIN the admitted stream, per-account rate limits + anti-bot preserve fairness IN the queue, regional allocation localizes contention; anchors 100K-300K QPS, 1M+ concurrent sessions, 5-30min window, oversell <0.01%
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will protect checkout by gating users through a queue."
- "Fairness and oversell prevention are top-level design goals."