Preview — Pro guide
You are seeing a portion of this guide. Sign in and upgrade to unlock the full article, quizzes, and interview answers.
Design an Event Ticketing System (BookMyShow / Ticketmaster)
System design deep-dive for a flash-sale ticketing platform at Ticketmaster scale — 600K+ concurrent users competing for 50K seats in seconds — covering seat reservation with TTL, oversell prevention via optimistic locking, virtual waiting rooms, WebSocket availability overlays, and idempotent payment flows.
Why Ticketing Systems Are a Concurrency-First Problem
An event ticketing system is the canonical example of a high-contention inventory problem — thousands of users competing for a finite, non-replenishable resource (seats) in a narrow time window. The numbers are brutal: when Ticketmaster opened Taylor Swift's Eras Tour on sale in November 2022, 3.5 billion system requests hit in a single day, with peaks well above 600K concurrent users fighting for seats. BookMyShow sees ~50M daily page views with transaction peaks of ~700K per hour during blockbuster releases. What makes this system harder than a typical inventory problem is the temporal nature of seat locks — you must hold a seat for a user during checkout (typically 10 minutes) without losing it to another buyer, but you must also release it if the user abandons. The core invariant: exactly one booking per seat, zero oversells, even under maximum contention. Interviewers testing senior engineers on this problem are evaluating three things: (1) whether you understand why naive database locking causes convoy effects at scale, (2) whether you know the two-phase reservation pattern, and (3) whether you can design a flash-sale queue that degrades gracefully instead of collapsing. Candidates who answer 'use SELECT FOR UPDATE' for seat locking fail the scale question — that approach serializes every concurrent checkout behind a database-level lock and produces cascading timeouts above ~10K TPS.
What Interviewers Are Actually Testing
The ticketing system question is a proxy for three deep topics. First, concurrency under contention: do you know the difference between optimistic and pessimistic locking, and do you know which outperforms at high concurrency? Second, distributed state management: how do you coordinate a 10-minute seat hold across stateless API servers? Third, graceful degradation: the 2022 Taylor Swift meltdown happened because Ticketmaster's verified fan system could not shed load fast enough — interviewers want to see a design that keeps working at 10% capacity when the queue is at 100x normal volume. Lead with the optimistic locking insight (pessimistic locking causes convoy effects), show the Redis SETNX seat lock with TTL, and demonstrate the waiting room with token-based admission.
Clarifying Questions to Ask Before Designing
What types of events?
Concerts, sports, theatre, or all three? Each has different seat models. Concerts often have zones (general admission, floor, seated tiers). Sports have fixed-seat maps with section/row/seat numbers. Theatre has both. This drives seat map complexity and selection UX.
Specific seat selection or best-available?
Specific seat selection (user picks seat 14C in row 3) requires a real-time seat map with availability overlay — much more complex. Best-available (system assigns the best open seat) is algorithmically simpler but less user-friendly. Ticketmaster supports both; assume specific seat selection for a senior design.
What is the expected concurrency at peak?
Flash sale (all at once) vs. rolling availability (seats released over time)? Flash sale is the hard case. Taylor Swift Eras Tour: 600K+ concurrent users for ~50K seats. BookMyShow IPL cricket finals: similar ratios. Target: design for 100K concurrent users fighting for 50K seats.
What is the seat hold timeout?
How long does a user get to complete checkout after selecting seats? BookMyShow uses 10 minutes. Ticketmaster uses 8–10 minutes. After expiry, seats return to available. This window directly sets your TTL for the Redis seat lock.
Payment integration depth?
Full payment processing in-band (user enters card, we charge Stripe), or redirect to a payment gateway? In-band is the harder design. Failure during payment with seats locked is the critical edge case.
Resale and transfer?
Is resale/ticket transfer in scope? This adds a secondary market state machine. Out of scope for the initial design unless explicitly asked.
Cancellation policy?
Can users cancel booked tickets? If yes, do seats return to inventory immediately or after a holdback window? This adds a cancellation state and inventory replenishment flow.