Hard · Travel and events
Concert ticket drop
Tickets for a huge tour go on sale at 10:00 sharp. Hundreds of thousands of fans arrive in the same minute, bots arrive earlier, and everyone refreshes when the page stalls. There are 40,000 seats. Sell each one once, charge each buyer once, and keep the site standing. Practise this hard system design problem for free with a Google or GitHub account.
The brief
Tickets for a huge tour go on sale at 10:00 sharp. Hundreds of thousands of fans arrive in the same minute, bots arrive earlier, and everyone refreshes when the page stalls. There are 40,000 seats. Sell each one once, charge each buyer once, and keep the site standing.
Think of a ticket sale like Ticketmaster.
Users, scale and requirements
- Who uses it
- 2 million fans on the day (approx.)
- Audience in plain numbers
- 2,000,000 users or devices
- Normal peak
- ≈ 600 requests per second
- Request mix
- Read: 57%; Sign-in: 10%; Write: 24%; Payment: 5%; Notification: 4%
- Speed for 99 of 100 requests
- Read: ≈ 500 ms; Sign-in: ≈ 1,500 ms; Write: ≈ 500 ms; Payment: ≈ 4,000 ms
- Successful requests
- 99%
- Data safety
- No acknowledged write may be lost.
- Monthly budget
- ≈ $16,000
- Data at rest
- ≈ 1 TB
- Where users are
- North America: 100%
- Home region
- North America
- Waiting deadlines
- Read: 900 seconds; Sign-in: 900 seconds; Write: 3,600 seconds; Payment: 3,600 seconds; Notification: 900 seconds
- Fresh reads
- People must see their own changes. At most 0.1% of reads may be stale in the model.
- Personal reads
- 40% of reads are private; a shared public copy cannot answer them.
- Required proofs
- Managed encryption keys; Audit trail
≈ marks an approximation, just as in the game. Waiting deadlines measure the age of queued work and are separate from interactive response time.
- Use the rush multiplier and the request mix to estimate seat holds and payments.
- The normal day is flat at about 600 requests a second. At 10:00 sharp, traffic jumps to about 25 times that for 15 minutes (approx.).
- One database primary handles about 2,000 writes a second; payments are limited by the card company to about 1,000 a second.
- Notification speed measures provider acceptance. Device receipt is outside this traffic model; check expiry, provider outcome and retries in the correctness trace before claiming delivery guarantees.
Questions that shape the design
Is it fine to make fans wait in line?
Yes. A fair waiting room is much better than a broken site. Fans wait if they are told their place.
Can a seat be sold twice?
Never. A seat is held for one buyer for 5 minutes, then sold or released.
What about people who press refresh?
Many will. Every refresh can add load, and a failing payment may be retried several times by the app.
Can some requests be turned away?
A small share, yes, if bots and extra refreshes are the ones turned away. 99 percent of real people should be served.
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.
09:50 · 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.
10:00 · Flash crowd
A scheduled launch brings a sudden rush of requests.
Traffic reaches 25 times the scheduled load; rises over 30 seconds, holds for 900 seconds and eases over 1,800 seconds.
10:07 · Retry storm
A brief failure causes clients to retry, adding load while the service recovers.
Failed calls: 90%. Duration: ≈ 30 seconds. Duration: ≈ 1,200 seconds.
What a strong design has to handle
- The site does not have to serve everyone at once. What could hold people in a fair line and let them in at a pace your database can handle?
- Sell each seat once with fenced expiring holds and recoverable payment.
- A waiting room feels slow to a fan and stops the site from falling over. Most fans prefer a place in line to an error page.
- A rate limiter set to fail closed turns people away if it breaks. Fail open lets bots through. For a sale, closed is usually the safer choice.
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
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.
- Hard
Bulk text campaigns
Businesses send a coupon or an alert to hundreds of thousands of phones at once. Carriers accept texts only at a fixed speed, every text costs real money, and a person who replied STOP must never be texted again. Delivery receipts come back by the thousand and must be counted.
- 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.