Design Ticketmaster / BookMyShow — Cheat Sheet

Ticketing is a study in contrasts: browsing events is a massive, cache-friendly read workload, while booking a specific seat demands strict correctness — the same seat must never be sold twice. The heart of the design is a short-lived seat reservation (a hold with a TTL) backed by a strongly consistent store, plus a virtual waiting room to survive flash sales like a Taylor Swift on-sale.

• ✓Browse and search events, venues, and showtimes
• ✓View a live seat map with available / held / sold seats
• ✓Reserve (hold) one or more seats for a limited time
• ✓Pay and confirm the booking; release the hold if payment fails or times out
• ✓Prevent double-booking — a seat is sold to at most one user
• ✓Strong consistency for seat inventory (correctness over availability)

• ✓Browse reads: ~50k RPS at peak (cacheable)
• ✓Flash-sale users: 100k+ concurrent on one on-sale
• ✓Seats per event: 1k – 100k
• ✓Hold TTL: 10 minutes
• ✓Booking writes: low volume, high correctness

• ✓API Gateway / Load Balancer — TLS, auth, rate limiting, and routing. During an on-sale it also admits users from the virtual waiting room in controlled batches.
• ✓Search Service (Elasticsearch) — Full-text and faceted search over events, artists, venues, and dates. Sourced asynchronously from the events database so search load never touches the transactional path.
• ✓Inventory / Booking Service (relational DB) — The source of truth for seats. Uses a strongly consistent relational database (PostgreSQL) with row-level locking (SELECT ... FOR UPDATE) or optimistic version checks so a seat can transition available → held → sold exactly once.
• ✓Reservation Store (Redis) — Holds short-lived seat reservations as keys with a 10-minute TTL. A hold is an atomic Redis operation; when the TTL expires the seat is automatically freed without any cron job.
• ✓Payment Service (idempotent) — Integrates the payment gateway behind an idempotency key so a retried request never double-charges. On success it commits the booking (held → sold) in one transaction; on failure/timeout the hold is released.
• ✓Virtual Waiting Room + Queue (Kafka) — During flash sales, users enter a queue and are admitted in batches. This shields the inventory database from a 100k-user thundering herd and gives users a fair, predictable position.

• ✓Consistency model for seat inventory → Strong consistency (CP): Selling the same seat twice is unacceptable. Booking chooses consistency over availability; browsing (a separate path) can stay highly available and cached.
• ✓Inventory store: SQL vs. NoSQL → Relational (SQL) with row locking: Seat sales need ACID transactions and serializable commits. This is exactly what relational databases are built for; eventual-consistency stores would risk oversell.
• ✓How to hold a seat during checkout → Redis key with a TTL: A hold with automatic expiry frees abandoned seats with no background job, and an atomic SET NX resolves races between users cleanly.
• ✓Handling on-sale spikes → Virtual waiting room + batched admission: Admitting users in controlled batches protects the transactional database from a 100k-user thundering herd and gives fair, visible queue positions.

• ✓Split the problem immediately: browsing is a cacheable read workload; booking is a strict-correctness write workload. They get different architectures.
• ✓The held state (reservation with TTL) is the key idea — describe available → held → sold explicitly.
• ✓Name your double-booking defense: SELECT ... FOR UPDATE or an optimistic version check in the DB, not app-level checks.
• ✓Bring up the virtual waiting room for flash sales before the interviewer asks "what about Taylor Swift on-sale?".
• ✓Payments must be idempotent — mention the idempotency key and why retries would otherwise double-charge.
• ✓Lean on Redis TTL to auto-release abandoned holds instead of a cron sweeper.