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.3 What are the doors?
3 min read+10 XP
Step 3: API and data model (10 minutes)
POST /v1/sales/{id}/join (from 09:45; one spot per account)
returns: { "queue_token": "q_…", "position": 600123, "eta_s": 300 }
GET /v1/sales/{id}/queue?token=… (cheap, cached status poll)
returns: { "position": 412000, "eta_s": 206 } or { "admitted": true, "admission_token": "a_…" } or { "sold_out": true }
POST /v1/holds Authorization: admission_token
body: { "section": "B", "count": 2 }
returns: { "hold_id": "h_9", "seats": ["B-14", "B-15"], "expires_at": "10:07:31" }
POST /v1/holds/{id}/pay Idempotency-Key: … → 202 (payment flow, Chapter 42)
The admission token is signed and short-lived: booking endpoints refuse anyone without one, so skipping the queue is impossible.