Ticketmaster — Event Ticketing

Design Ticketmaster. Concert tickets go on sale at 10am; 500K users try to grab 40K seats simultaneously. No double-bookings. Fair queue.

Time budget: 45 min whiteboard. Draw architecture, estimate numbers, discuss tradeoffs.

Hint 1

Waiting room (FIFO queue) before the seat-picker even loads. Users enter in batches.

Hint 2

Seat hold pattern: soft hold with TTL (5 min) while user picks + pays. Explicit release on timeout.

Hint 3

Pessimistic lock on seat row at commit time — NOT optimistic. 100K users on same seat = 99,999 retry-storm.

• +2 Waiting room FIFO queue as frontline; admits N users/sec to the seat picker
• +2 Seat hold with explicit TTL (5 min); automatic release on timeout; atomic swap on purchase
• +2 Pessimistic lock on seat rows (not optimistic) — avoids thundering-herd retries on popular seats
• +1 Inventory cache (Redis) for 'seats remaining' reads; authoritative lock in DB for writes
• +1 Anti-bot: captcha, rate-limit per IP/account, proof-of-work or challenge on suspicious
• +1 Payment saga: hold seat → auth payment → confirm purchase → release hold on fail
• +1 Pre-allocation: seats assigned to ticketing groups (resellers/presale) before public sale

Self-score: tally the points you would have mentioned unprompted. 7+ is interview-ready on this problem.

• Optimistic concurrency on popular seats (retry storms — 99K failures per seat)
• Cache seat availability aggressively (users all see 'available' for same seat)
• One big DB transaction from 'pick seat' through 'type card info' (locks for minutes)
• No waiting room — 500K users hit seat-picker at t=0
• No bot protection