Design a Ticket Booking System (Ticketmaster / BookMyShow)
An end-to-end interview-ready walkthrough — from capacity estimation through deep dives on seat state machines, virtual waiting rooms, distributed locking, payment sagas, and bot prevention. Structured to mirror the arc of a 45-minute system design interview.
Requirements
A ticket booking system is deceptively simple on the surface — "user picks a seat, pays, gets a ticket." But at Ticketmaster/BookMyShow scale, you're solving one of the hardest concurrency problems in distributed systems: millions of users competing for a finite, non-fungible resource (a specific seat) within a narrow time window. Unlike e-commerce where you can oversell and backorder, a seat is a unique physical resource that cannot be duplicated. The core tension is that you need strong consistency for a tiny window (seat reservation) while serving millions of concurrent users who expect real-time feedback.
Functional Requirements
Core business logic & features
- 01.Browse Events & VenuesUsers can discover events by category, location, date, and artist. View venue seat maps with section/row/seat layout.
- 02.Search & FilterFull-text search across events, artists, venues. Filter by date range, price range, genre, and availability.
- 03.Reserve & Purchase SeatsUsers select specific seats (or best-available), hold them temporarily, and complete payment within a time window.
- 04.Prevent Double-BookingA seat can only be sold to exactly one user. No overselling, no race conditions, no duplicate reservations.
- 05.Seat Hold with ExpirationHeld seats are locked for 10 minutes. If payment isn't completed, seats are automatically released back to inventory.
- 06.Real-Time Seat AvailabilitySeat map updates in near real-time as seats are held/released. Users see current availability without full page refresh.
Non-Functional
System constraints
Consistency
Zero overselling. A seat must never be sold to two users. Strong consistency on the write path for inventory.
Scale
Handle 10M+ concurrent users during a high-demand launch. 50K seats sold in <2 minutes for top-tier events.
Latency
Seat hold confirmation in <500ms. Seat map refresh in <2s. Payment processing in <5s end-to-end.
Availability
99.99% uptime during active sales. Graceful degradation under extreme load — queue users rather than crash.
🎯 Clarifying questions that change the design
Each of these steers you toward a fundamentally different architecture:
- Assigned seating or general admission? Assigned seating requires per-seat locking (row-level concurrency). General admission is a simple counter decrement (much easier). Most interviews expect assigned seating.
- How long is the hold window? 5 minutes vs 15 minutes changes how aggressively you reclaim seats. Shorter holds = more churn, more contention on re-release.
- Do we support "best available" selection? If yes, the system must atomically find AND reserve the best N seats — a much harder problem than reserving user-selected seats.
- What's the peak concurrent demand? A local theater (1K users) vs Taylor Swift (10M users) requires fundamentally different architectures. The waiting room pattern only matters at extreme scale.
- Multi-region or single-region? If the event is in one city, a single-region deployment with strong consistency is simpler. Global events need careful partition strategy.
- Resale/transfer support? Secondary market adds ownership transfer, price validation, and fraud detection — scope it out unless asked.
In scope vs out of scope
| In Scope | Out of Scope | Why |
|---|---|---|
| Assigned seat selection and reservation | General admission (counter-based) | Assigned seating is the hard problem — GA is a simple atomic decrement |
| Temporary seat holds with TTL expiration | Permanent reservations without payment | Hold-then-pay is the standard two-phase booking flow |
| Payment processing with saga pattern | Full payment gateway implementation | We design the orchestration, not the Stripe/Razorpay internals |
| Virtual waiting room for demand spikes | DDoS protection infrastructure | Waiting room is application-level; DDoS is network-level (Cloudflare) |
| Real-time seat availability updates | Live event streaming / video | Seat map is a state-sync problem, not a media delivery problem |
| Bot prevention and fairness mechanisms | Full anti-fraud / identity verification | We cover queue fairness and CAPTCHA; KYC is a separate system |
| Booking confirmation and e-tickets | Venue entry / QR code scanning | Ticket generation is in scope; physical access control is not |
💡 Interviewer signal
The strongest opening: "I'll focus on the seat reservation pipeline — that's where the distributed systems complexity lives. The core challenge is preventing double-booking under extreme concurrency while maintaining sub-second response times for millions of simultaneous users. I'll cover the waiting room for traffic shaping, Redis-based seat holds with TTL, and the payment saga for atomicity. Event discovery is a read-heavy caching problem I'll address separately." This shows you know where the hard problems are.