Medium · Commerce and retail
Flash sale inventory
At noon a hot item goes on sale with only a few thousand units. A huge crowd arrives in the same minute and everyone taps Buy. Stock must never go below zero, nobody should be charged for an item that is gone, and the site must not fall over. Practise this medium system design problem for free with a Google or GitHub account.
The brief
At noon a hot item goes on sale with only a few thousand units. A huge crowd arrives in the same minute and everyone taps Buy. Stock must never go below zero, nobody should be charged for an item that is gone, and the site must not fall over.
Think of a limited-stock sale like a sneaker drop.
Users, scale and requirements
- Who uses it
- 4 million shoppers on the day (approx.)
- Audience in plain numbers
- 4,000,000 users or devices
- Normal peak
- ≈ 2,500 requests per second
- Request mix
- Read: 65%; Write: 30%; Payment: 5%
- Speed for 99 of 100 requests
- Read: ≈ 600 ms; Write: ≈ 600 ms; Payment: ≈ 4,000 ms
- Successful requests
- 99.9%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $13,000
- Data at rest
- ≈ 0.5 TB
- Where users are
- North America: 70%; Europe: 30%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Write: 3,600 seconds; Payment: 3,600 seconds
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- Inventory is limited. Use the request mix to estimate how fast buy attempts arrive.
- One item row is the hot key everyone fights over.
- All numbers are rough approximations.
Questions that shape the design
Can we sell more than we have?
Never. Overselling means cancelled orders and angry buyers.
Must buyers get an instant answer?
They need to know their order was received within a second. Confirmation can follow shortly after.
Can some buyers be turned away?
Yes. Stock is tiny compared with the crowd, so most people will see "sold out". That is fine if it is fast and honest.
The traffic day
A quiet baseline followed by the scheduled rush. The clock covers 00:00 to 24:00 in the home region. Events add pressure on top of that normal traffic.
12:00 · Synchronized rush
Many callers send requests together instead of spreading them over time.
Traffic for Read reaches 3 times the scheduled load; rises over 10 seconds, holds for 60 seconds and eases over 300 seconds. Other request types keep their scheduled load.
12:05 · Bot scraping
Bots try stolen passwords and scrape pages, adding unwanted traffic.
Extra attack traffic is 0.5 times the configured peak. Duration: ≈ 7,200 seconds.
What a strong design has to handle
- Millions fight over one number: the units left. What makes the count safe, and what keeps the crowd away from it?
- Reserve stock once and settle payment against the surviving reservation.
- A queue gives a "received" answer fast and protects the stock, but the final yes or no arrives a moment later.
- Rate limiting at the edge keeps bots out, but a strict limit can also turn away real buyers on a shared network.
Make a prediction, run a full traffic day, then compare the result. The in-game editorial opens after a finished day and includes measured reference designs.
Concepts to practise
Related problems
- Hard
Black Friday marketplace
Once a year a marketplace puts thousands of deals live at the same minute. Millions browse and search, a few doorbuster items get hammered, and a smaller crowd checks out. A payment must never be taken twice, and the day must survive the card processor having a bad hour.
- Medium
Rate limiter for a public API
Developers call your public API from scripts and apps. A few misbehaving or malicious clients can crowd out everyone else. Build limits that are fair, fast and cheap, and that survive a retry storm.
- Medium
Notification service
Every other team asks you to send messages: order shipped, new login, a sale starting. You send them by push, email and text through outside providers who have their own limits. Send each message once, and never block the team that asked.
- Hard
Scheduled job service
Customers register jobs: "call my web address every night at 02:00" or "every hour on the hour". Aim to fire within 5 seconds; work still waiting after 60 seconds counts as failed. Retry safely after a crash. One external effect requires the customer endpoint to honor a stable job occurrence key. Half the world picks the top of the hour, so a huge crowd of jobs comes due in the same second.