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.5 What does the whole system look like?
3 min read+10 XP
Step 4: High-level design (10 minutes)
Figure: the final design. Booking is sized for the admit rate, not for everyone pressing refresh.
The sale, step by step:
- Before 10:00, people see a static countdown page served by the CDN; refreshing it costs us nothing.
- People join the waiting room (one spot per account). Edge checks filter obvious bots (43.8).
- At 10:00, the waiting room starts admitting people at 2,000 a second, in an order that's fair (43.9), each with a signed admission token that expires if unused.
- Admitted buyers pick a section and hold seats for 5 minutes (43.7).
- They pay (Chapter 42's flow); paid holds become tickets; unpaid holds expire and the seats return to sale.
- When seats run out, everyone still waiting is told "sold out" immediately.
Interviewer pushback:
- "The waiting room itself gets 2 million requests." → It's simple and cheap: one write to join, then cached status polls every few seconds (and the position can be computed from a counter). It can be a managed service, an edge worker, or a Redis-backed queue, scaled for the burst.
- "Someone shares their admission token." → Tokens are bound to the account (and device), so a shared token doesn't work for another account.
Memory code: "Count down at the edge, queue cheaply, admit at the speed of seats."
Offer: "The interesting parts are the waiting room, seat locking, bots, and fairness. Which would you like?"