Art of Codeartofcode
Lesson 5 of 15

43. Design Flash-Sale Ticket Booking (Ticketmaster / IRCTC Tatkal)

1
The interview prompt
2
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 yourself
13
Variations to practise
14
Sources
15
Code lab
43. Design Flash-Sale Ticket Booking (Ticketmaster / IRCTC Tatkal)

43.4 What do we store?

3 min read+10 XP
queue (in-memory store, Redis) sale_id → ordered list of account IDs; account → position admissions admission tokens: account, sale, expires_at (signed, so mostly stateless) seats (SQL, by section) seat_id, status (free | held | sold), hold_id, hold_expires holds hold_id, account, seats, expires_at, payment state tickets ticket_id, seat_id, account, issued_at

Interviewer pushback:

  • "Why seats by section?" → Holds for different sections never touch the same rows, so sections spread the write load; a buyer picks a section, and best-available search stays within it.

Memory code: "A token to wait, a token to enter, a hold to pay."