Design a Ticket Booking System
Design a ticket selling/booking service like Ticketmaster where users can book individual seats or just general admission.
Asked at:
Meta
Apple
Amazon
A ticket booking system like Ticketmaster lets people discover events, pick specific seats or general admission quantities, place a short hold, pay, and receive digital tickets. Think concerts, theater, sports, movies, or even airline seats—users expect live availability, fair access during surges, and a smooth checkout. Interviewers ask this because it forces you to reason about extreme contention on a tiny inventory set, short-lived reservations with expiration, correctness under retries, and fairness controls (waiting rooms). It also touches payment orchestration, idempotency, and real-time updates—skills that map to many high-stakes, stateful product flows beyond ticketing.
Hello Interview Answer Key
Design Ticketmaster
System design answer key for designing a ticket booking service like Ticketmaster, built by FAANG managers and staff engineers.
Common Functional Requirements
Most candidates end up covering this set of core functionalities
Users should be able to discover and search for events by keyword, date, and location.
Users should be able to view ticket availability, including seat maps for reserved seating and quantities for general admission.
Users should be able to place a short reservation hold on selected tickets that automatically expires.
Users should be able to complete purchase, including payment, and receive a confirmed booking with tickets.
Common Deep Dives
Common follow-up questions interviewers like to ask for this question
This is where interviewers test your ability to make a single source of truth decision under load. You need atomicity, short critical sections, and a design that never trusts stale reads when deciding to sell a ticket. - For GA inventory, consider an atomic decrement that only succeeds if stock remains (e.g., a Redis Lua script or DB-side compare-and-swap). You should return failure immediately when stock is insufficient. - For seat maps, you could use optimistic concurrency (version columns/unique constraints) or a short-lived distributed lock with TTL per seat. Keep the lock scope tiny and the critical section idempotent. - Validate ownership on finalize: you should ensure the same user/session that reserved the seat is the one booking it, and recheck that the reservation is still valid before marking SOLD.
Reservations with expiration are central to a good UX and a common failure point in system design interviews. The goal is to hold tickets without wedging inventory if clients fail, crash, or abandon checkout. - Use a state+expiry model (AVAILABLE → RESERVED until expiresAt → BOOKED) with conditional updates. You could reclaim expired holds via a background sweeper and treat expired reservations as AVAILABLE on read. - Consider Redis locks or hold records with TTL keyed by seat/GA-bucket+user. You should make writes idempotent so retries safely extend/refresh holds. - Keep payment and reservation lifecycles decoupled: you could authorize payment during the hold and capture only after you atomically flip to BOOKED.
High-demand drops create stampedes that can overwhelm downstream services and disadvantage legitimate users. A waiting room gates admission, smooths load, and improves perceived fairness. - Gate at the edge using an admission token and a queue. You could randomize entry or shard queues to reduce hot spots, and admit at a rate that matches downstream throughput. - Provide real-time progress via WebSockets/SSE to reduce churn; you should communicate estimated wait times and pause/resume on incidents. - Enforce bot protections and per-user/device rate limits; you could bind tokens to device/user and set strict expiration to prevent token reuse.
Real systems face network flakiness and out-of-order webhooks from payment processors. Interviewers want to see explicit state transitions and idempotency boundaries. - Use idempotency keys (e.g., bookingId) on all write operations. You could persist outcomes and return the last known result on retries. - Apply an outbox/inbox pattern for reliable event emission and deduplication. You should base transitions on current state, not assumptions about call order. - On payment success, perform a single transaction: verify the reservation is yours and unexpired, mark tickets BOOKED, capture funds, and emit events. You could safely ignore duplicate webhooks by checking state.
Relevant Patterns
Relevant patterns that you should know for this question
Ticket drops concentrate massive write contention on a tiny set of seats or a single GA counter. You need atomic updates, short critical sections, and fairness controls to avoid oversells and meltdown.
Checkout spans reservation, payment authorization/capture, and ticket issuance. Modeling this as a clear state machine or saga with compensations and idempotency is essential for correctness.
Users expect live seat map changes, queue position updates, and hold countdowns. Push-based updates (WebSockets/SSE) reduce wasteful polling and improve UX during high demand.
Relevant Technologies
Relevant technologies that could be used to solve this question
PostgreSQL delivers strong transactional guarantees for seat states, reservations, and bookings. Optimistic concurrency control, unique constraints, and short transactions help ensure no double-sell.
Similar Problems to Practice
Related problems to practice for this question
It is the canonical version of this problem: reserved seating vs GA, extreme contention, reservation expiry, virtual waiting rooms, and payment finalization.
Both have intense competition for scarce items, require strict correctness under concurrent writes, and benefit from fairness mechanisms and idempotent operations.
Booking flows rely on payment authorization/capture, idempotency keys, webhook handling, and state-machine design that mirrors a Stripe-like integration.
Red Flags to Avoid
Common mistakes that can sink candidates in an interview
Holding long database locks or interactive transactions for the entire reservation window
This ties up scarce resources, risks deadlocks, and collapses under load. A crash could wedge inventory indefinitely and the system won’t scale during surges.
No admission control or waiting room during high-demand events
Letting everyone hit the booking endpoints creates cascading failures, timeouts, and an unfair race. A queue protects downstream services and improves fairness.
Missing idempotency and explicit state transitions across payment and booking
Without idempotency keys, an outbox/inbox, and clear state checks, retries and out-of-order webhooks can cause double charges, double bookings, or orphaned holds.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late August, 2025
Meta
Manager
Late August, 2025
Meta
Senior
Mid August, 2025
Meta
Staff
Your account is free and you can post anonymously if you choose.