43. Design Flash-Sale Ticket Booking (Ticketmaster / IRCTC Tatkal)
1
The interview prompt2
43.1 What do you ask first?3
43.2 How big is this, really?4
43.3 What are the doors?5
43.4 What do we store?6
43.5 What does the whole system look like?7
43.6 How does the waiting room work?8
43.7 How does seat locking work?9
43.8 How do you rate-limit bots?10
43.9 How do you keep it fair?11
43.10 What would you say in the last five minutes?12
Score yourself13
Variations to practise14
Sources15
Code lab43. Design Flash-Sale Ticket Booking (Ticketmaster / IRCTC Tatkal)
43.2 How big is this, really?
3 min read+10 XP
Step 2: Estimates (5 minutes)
Assume booking can safely handle 2,000 admissions a second (seat selection, hold and payment start), and a 5-minute payment hold.
| What | Working | Result |
|---|---|---|
| People per seat | 2,000,000 ÷ 50,000 | 40 per seat: most won't get one |
| Wait for position 600,000 | 600,000 ÷ 2,000 a second | ≈ 5 minutes |
| Admitted in 10 minutes | 2,000 × 600 | 1.2 million (seats sell out long before) |
| Refreshes at 10:00 if no waiting room | 2 million people × a refresh every few seconds | hundreds of thousands to millions of requests a second on dynamic pages |
| Abandoned holds | say 20% of 50,000 | 10,000 seats come back after 5 minutes |
What the numbers say, out loud:
- "Supply is the limit, not servers. The system's job is to meter people into booking and tell everyone else the truth quickly."
- "The refresh storm is the real load: make the waiting page static and cached at the CDN (Chapter 26), with a cheap status poll."
- "Seats will be released by abandoned holds, so the sale has a second wave a few minutes in."
Interviewer pushback:
- "Why 2,000 a second?" → It's set by what the seat inventory and payment provider can handle safely (measured in load tests), not by how many people are waiting.
Memory code: "Forty people per seat: meter them in, and tell the rest the truth."