Lesson 6 of 15
43. 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)

people pass edge bot checks into a waiting room that admits 2,000 a second with signed tokens; the booking API holds seats for 5 minutes; payment and tickets follow; a static countdown page on the CDN absorbs the pre-open storm.

Figure: the final design. Booking is sized for the admit rate, not for everyone pressing refresh.

The sale, step by step:

  1. Before 10:00, people see a static countdown page served by the CDN; refreshing it costs us nothing.
  2. People join the waiting room (one spot per account). Edge checks filter obvious bots (43.8).
  3. 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.
  4. Admitted buyers pick a section and hold seats for 5 minutes (43.7).
  5. They pay (Chapter 42's flow); paid holds become tickets; unpaid holds expire and the seats return to sale.
  6. 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?"