System Design (High-Level Design) Module 26 – Case studies: booking, commerce and contention
Design a flash sale system
Design a flash sale: a sale page served by a CDN, a waiting room, stock taken atomically in memory, and orders created from a queue.
What you will learn
- Estimate the first seconds of a flash sale and the parts that must absorb them
- Design a stock gate that sells a fixed number of units to a huge crowd without overselling
- Move order creation off the hot path with a queue and idempotent consumers
- Prevent a failover of the in-memory counter from selling any unit twice
- Design fairness limits and the reconciliation that runs after the sale
Before you start
What you’ll learn · Before you start
What you will learn
- Estimate the first seconds of a flash sale and the parts that must absorb them
- Design a stock gate that sells a fixed number of units to a huge crowd without overselling
- Move order creation off the hot path with a queue and idempotent consumers
- Prevent a failover of the in-memory counter from selling any unit twice
- Design fairness limits and the reconciliation that runs after the sale
Before you start
On this page
A flash sale sells a fixed number of units, say 1,000 phones, to a crowd hundreds of times larger, at a start time everyone knows. The design keeps that crowd away from anything that can fall over. The sale page is static and served by a CDN. Buyers join a waiting room that gives one ticket per account. Admitted buyers reach a stock gate that keeps the count in memory and decides each attempt in one atomic step: it checks the account’s limit, takes a unit and returns the unit’s number.
Winners become orders from a queue, at a pace the order database can take, and pay within a short window. After the sale, a reconciliation compares the counter with the orders, puts unpaid units back and refunds anything that went wrong. First you size the opening seconds yourself and follow one buyer through that design.
Two million buyers for a thousand phones, and a design that survives them
What makes a flash sale different
Everything happens in the first seconds, and almost every attempt must fail: with 1,000 units and hundreds of thousands of buyers, more than 99 % of attempts end in “sold out”. The stock is one count for one item, so the whole crowd competes for a single value, unlike seats, which spread buyers over many rows. And scripts compete with people, because a sale whose units are worth reselling attracts automation that is faster than any person.
Walk through the minutes the design is sized for, from the page load to the checks after the sale:
- The minute before
Everyone loads the sale page
Nearly everyone who wants a unit opens the page, its images and the sold-out flag before the start, so the page must be static, the same for everyone and cacheable.
- The first seconds
Almost every attempt must fail the peak
Most buyers press Buy within seconds of the start and only 1,000 of them can win, so a refusal has to be the cheapest answer the system gives, and an honest one.
- Seconds later
Winners become orders
Each win waits in an order queue, and order workers create the orders at a pace the order database can take, so the database never meets the crowd.
- The next 10 minutes
Winners pay
Every winner has a window of 10 minutes to pay, and a unit that is not paid for goes to the next buyers in line.
- After the sale
The counts are reconciled
The counter, the orders and the payments are compared with the units on sale, unpaid units are released, and anything that went wrong is refunded.
The timeline has 5 events, from The minute before to After the sale.
Requirements
Buyers see the sale page before the start and a clear state at every moment: not started, open, sold out. Each account may buy at most a set number of units, here 2. Exactly the units on sale are sold, never one more, and every winner gets an order and a window of 10 minutes to pay. Units that are not paid for go to the next buyers in line. The rest of the shop keeps working during the sale.
Estimates
Assume 2,000,000 people waiting for 1,000 phones, 30 % of them pressing Buy in the first 10 seconds, a 150 KB sale page loaded by everyone in the minute before the start, and order workers that create 200 orders a second. Work each figure out, then check yourself.
Checkpoint
Check the estimate
| Quantity | Working | Result |
|---|---|---|
| Attempts, first 10 seconds | 2,000,000 × 30 % ÷ 10 s | 60,000 a second |
| Page traffic, the minute before | 2,000,000 × 150 KB × 8 ÷ 60 s | 40 Gbit/s |
| Attempts that can succeed | 1,000 ÷ 600,000 | about 0.17 % |
| Creating every order | 1,000 ÷ 200 a second | 5 seconds |
The page traffic is the largest number and the easiest to serve; the attempts are the hardest.
The first design
The first design of a flash sale
Text description of the diagram
The diagram shows the path of a purchase from top to bottom.
- Buyers load the sale page, its images and a sold-out flag from a CDN.
- To buy, they join a waiting room that gives one ticket per account.
- Admitted buyers call the buy API, which checks their admission token.
- The API asks the stock gate, which keeps the stock in memory and decides each attempt in one atomic step: the account's limit, the stock left and a unit number.
- Winners go to an order queue, and order workers create the orders in the orders database, which accepts one order per unit.
- Each order is paid within 10 minutes.
- A dashed arrow leads from the orders to the work after the sale: reconciling the counts and releasing units that were not paid for.
The CDN serves the page, its images and a small sold-out flag that changes once. The waiting room gives one ticket per account and admits buyers at a set rate. The buy API checks each admission token and asks the stock gate, an in-memory store that decides each attempt in one atomic step. Winners go to an order queue; order workers create the orders, one per unit, and buyers pay. After the sale, the counts are reconciled and unpaid units released.
Step through one buyer’s attempt, from the sale page to the paid order:
The drawing shows the whole scene; its 7 steps are listed below.
Every step as text
- The page comes from the CDN. Before the start, the buyer loads the sale page, its images and a small sold-out flag from the CDN. Every buyer gets the same files, so the origin serves almost nothing.
- One ticket per account. To buy, the buyer joins the waiting room, which gives each account one ticket and lets ticket holders in at a set rate.
- Let in with a token. When the buyer's turn comes, the waiting room hands over an admission token, and only then does the attempt reach the buy API, which checks the token.
- One atomic step. The buy API asks the stock gate. In one atomic step the gate checks the account's limit, takes a unit if one is left and returns the unit's number, here unit 417.
- A win joins the queue. The win waits in the order queue instead of writing to the order database, so the database works at its own pace and never meets the crowd.
- An order per unit. An order worker takes the win and creates the order. The orders database accepts one order per unit, and the buyer then has 10 minutes to pay.
- Paid within the window. The order is written, and the buyer pays within the window. After the sale, the counts are reconciled and the units nobody paid for are released.
Checkpoint
Check the first design
The deep-dive questions
- How does the stock gate sell exactly 1,000 units when tens of thousands of attempts arrive each second?
- Where is the limit per account enforced, and how is the sale kept fair against scripts?
- How are orders created from the queue exactly once, and what happens to units nobody pays for?
- What happens when the in-memory store’s primary fails in the middle of the sale?
- What does the reconciliation after the sale check?
- What breaks at 10× and 100×, and which designs are rejected?
The stock gate decides each attempt in one atomic step Pro: opens with a Pro, Premium or Ultimate pass
In this part:
- One atomic step against read, then decrement
- The limit per account belongs in the same step
- Fairness comes from one ticket per account and random early places
- One hot key, and when to split it into buckets
- Orders come from a queue, and the unit number makes repeats harmless
- Unpaid units go to the next buyers in the queue
- A failover can sell a unit twice, and the order store refuses it
- Reconciliation after the sale checks units, orders and payments
- At 10× the waiting room gives way first, and at 100× the page before the start
- Failure drills: five faults, each with a safe way out
- Options considered and rejected
- What each level covers, and a 45-minute self-mock
- What each level is expected to cover
- A 45-minute self-mock
- Practise: a stock gate, then the whole design
- Write a stock gate with a limit per account and unit numbers
- Interview questions
- Your flash sale takes stock with an atomic script in an in-memory store. Its primary fails 40 seconds into the sale and a replica takes over. Afterwards you find 37 more paid orders than units. Explain the mechanism and redesign so that a failover cannot oversell.
- One key holds the stock of a phone in a flash sale, and 400,000 attempts a second reach it in the first seconds. The shard's latency rises to seconds and attempts time out. How do you spread the load without overselling, and what does your change cost?
- In a flash sale, 30 % of the buyers who win a unit never pay within their 10-minute window. How do you put those units back on sale fairly, and how do you stop the same accounts from blocking stock again?
- Key takeaways
7 diagrams · 4 runnable examples (JavaScript, Python) · 1 exercise with sample tests · 3 interview answers · about 53 minutes
Opening this part with your pass…
This part opens with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so this part can’t be opened at the moment. The free part above stands on its own. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
Read a complete sample first: Design movie seat booking like BookMyShow
References
- Scripting with Lua (atomic script execution) (Redis)
- Redis replication (Redis)
- WAIT command reference (Redis)
- Queue-Based Load Leveling pattern (Azure Architecture Center) (Microsoft)
- RFC 9111: HTTP Caching (IETF)
- Stateful waiting room (Compute tutorial) (Fastly)
- OAT-005 Scalping (OWASP Automated Threats to Web Applications) (OWASP Foundation)
- OAT-021 Denial of Inventory (OWASP Automated Threats to Web Applications) (OWASP Foundation)
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress