System 12.19 — Ticket Booking (HLD)
In one line
BookMyShow at scale: multi-tenancy of venues, seat holds, and why inventory sells out 'evenly'.
Think of it like this
BookMyShow at the scale of an entire country: think of the Big Billion Day sale — thousands of people trying to grab the same 50 seats to a blockbuster's opening show in the same 10 seconds.
Key ideas
- 01
Wire the LLD (4.9) at scale: show schedules per venue, seat map per screen, holds with TTL, payments.
- 02
Scale peaks: a blockbuster release → 1M users fighting for 10k seats — the burst is the design driver.
- 03
Seat inventory: DB row per seat with version/hold-until; claim = UPDATE ... WHERE seat_status='AVAILABLE' (optimistic) or SELECT FOR UPDATE.
- 04
Queue/fairness: when demand >> supply, a waiting-room/queue (only N proceed per second) prevents a thundering herd.
- 05
Burst handling: pre-release 'reserve capacity' (venue ceilings), auth + rate limits, cache hot read paths (showtimes).
- 06
Timers: hold 7–10 min → release; payment timeout → release; sweeper job + in-memory expiry events.
- 07
Consistency: seat claims MUST be strong + atomic (the whole business is the tuple race); read paths can cache.
- 08
Interview: states the 'reserve → confirm/release' lifecycle with its timers, then the queue-fairness layer for hot shows.
Java / Spring map
- →
@Transactional seat claim with WHERE-guard; a scheduler for hold expiry; Redis rate limits + showtime cache.
Code & diagrams
The seat-hold state machine from Phase 4, now behind a queue that protects the DB from a flash-sale stampede.
Explain without notes
A 1M-user sale for 10k seats — why does the waiting-room + held-seat TTL survive where raw DB claims alone would not?
Practice
Design the hot-show queue (admit-rate, TTL of queue position) and the seat-release sweep.
Trade-offs
- ↔
Strong-seat-atomicity costs the claim a DB row lock under spike; the fair queue trades raw speed for conversation sanity.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can present seat lifecycle + burst queue + expiry machinery coherently.