Ticketmaster — Ticket Booking System

Ticket booking is fundamentally different from other inventory systems, and interviewers use this distinction to separate candidates who truly understand distributed systems from those who apply generic patterns. The critical difference is named seat reservation versus anonymous inventory units. A flash sale sells N identical, interchangeable items — the entire problem reduces to a single atomic counter (Redis DECR). Ticketmaster sells named seats: seat 14E in section 103 is a unique, specific resource with its own identity (section, row, number). This forces candidates to reason about per-entity locks versus shared counters, hold-and-confirm patterns, and seat map freshness at massive scale. The Ticketmaster interview question is uniquely rich because it exposes multiple independent hard problems simultaneously.

Three core challenges define the Ticketmaster design space. First, double-booking prevention: a seat sold means exactly one owner, with zero tolerance for overselling. Unlike hotel overbooking (which is sometimes deliberate), ticket double-booking is a catastrophic business failure — two people show up to the same seat. The system must enforce mutual exclusion at the per-seat level with no gaps. Second, the thundering herd problem at onsale: when a high-demand artist releases tickets, 5 million fans simultaneously attempt to access the seat map and hold seats the instant the sale opens. Every user hits the system at the same millisecond. Traditional rate limiting and queueing strategies break down because the bottleneck is not sustained load but an instantaneous spike. Third, seat map freshness: those 5 million concurrent viewers need to see a near-real-time availability overlay for 60,000 seats. Showing a seat as available when it was actually held 1.9 seconds ago creates user frustration — they click a seat and get SEAT_UNAVAILABLE. The system must balance freshness (low staleness) against the cost of serving 5M concurrent reads.

The reason Ticketmaster is architecturally different from a flash sale is subtle but important. A flash sale uses one shared inventory counter — Redis DECR on a single key. This creates a hot-key problem: all 5M users hammering one Redis key in parallel. Ticketmaster has 60,000 independent seat keys. Redis SETNX per seat key means there is no contention between different seats — seat 14E and seat 15F can both be held simultaneously without any coordination. This eliminates the hot-key problem entirely. But it introduces the seat map challenge: how do you serve a real-time availability overlay for 60,000 named seats to millions of concurrent viewers without reading all 60,000 Redis keys per render? The answer requires a dedicated availability cache with a compact bitmap representation.

The hold-and-confirm pattern is central to every viable Ticketmaster design. When a user selects a seat, the system places a 10-minute hold via a Redis SETNX call with a 600-second TTL. The user then enters payment details and completes checkout. If the payment succeeds, the hold is converted to a confirmed purchase written to the orders database. If payment fails or the user abandons checkout, the Redis TTL expires and the seat automatically returns to availability — no manual cleanup required. This two-phase approach decouples the instantaneous seat reservation (2ms Redis SETNX) from the slow, fallible payment process (200-500ms, 2-5% failure rate). The 10-minute window is deliberately chosen: short enough to prevent seat hoarding, long enough for payment flows to complete even on slow connections.

The Ticketmaster interview question is asked at Ticketmaster directly, as well as StubHub, AXS, Amazon Events, Eventbrite, and Walmart. The same patterns appear across the entire reservation industry: airline seat selection (delta.com forces holds during payment), movie ticket booking (AMC, Fandango), sporting event ticketing, hotel room booking, restaurant reservation systems, and parking spot booking. Any system where a specific named resource must be exclusively reserved for one user during a checkout flow is a Ticketmaster variant. Mastering this design covers a broad class of reservation problems that appear across every industry vertical.

The V1 canonical architecture uses 10 components organized into two independent paths: the event browse path (read-heavy, cacheable) and the seat hold path (write-critical, latency-sensitive). Understanding why these paths are separated — and why they must stay separated — is the architectural insight that drives the entire design.

The browse path handles 99% of all traffic by volume. Users searching for events, viewing event details, and rendering seat maps are served by SearchService backed by EventCache (ElastiCache Redis). EventCache maintains two distinct cache spaces with different TTLs: event metadata (artist, venue, date, pricing tiers) is cached for 60 seconds since it changes rarely, and seat availability overlays are cached for only 2 seconds since they change constantly during onsale. The browse read-to-purchase ratio is approximately 100:1 — for every ticket sold, 100 users browse without buying. Serving this read traffic from cache means EventDB (PostgreSQL) sees only cache miss traffic, roughly 1% of browse requests.

The seat hold path handles the critical 1% of traffic that actually moves money and inventory. When a user selects a seat, SeatService executes Redis SETNX on the key seat:{event_id}:{seat_id} with a 600-second TTL. SETNX is atomic and single-round-trip: it succeeds only if the key does not already exist, providing mutual exclusion with no race conditions. The 2ms Redis SETNX latency versus 50ms PostgreSQL SELECT FOR UPDATE (V0 approach) is a 25x improvement, and critically, different seats can be held simultaneously in parallel since each has its own independent key. 60,000 seats equals 60,000 independent parallel operations.

SeatHoldCache stores all active seat holds. The key is seat:{event_id}:{seat_id} and the value contains user ID, hold timestamp, and expiry. When a hold expires (Redis TTL auto-deletion), the seat silently returns to availability on the next EventCache invalidation cycle. SeatService triggers an EventCache invalidation on every successful SETNX, so the seat map availability bitmap is refreshed within 2 seconds. On confirmation, SeatService writes an order record to OrderDB (PostgreSQL RDS Multi-AZ) and publishes a ticket_confirmed event to TicketStream (Kafka).

TicketWorker consumes from TicketStream and handles QR barcode generation and email delivery asynchronously. This decoupling is critical: QR generation and email add 100-200ms to the checkout flow. At 5,000 concurrent confirmations during onsale, blocking on these operations would saturate service threads. Kafka decouples confirmation (instant) from delivery (within 30 seconds). Kafka also provides replay capability: if the email provider goes down, TicketWorker can reprocess events when it recovers without losing any confirmed orders.

The key metric that reveals the design's correctness is the read-to-write ratio: EventCache handles 5M browse RPS at 99% hit rate, meaning SearchService serves 4.95M RPS from in-memory cache. SeatService handles 50K seat hold RPS at onsale peak. These two services have radically different scaling needs — SearchService scales for read concurrency (many pods, large EventCache), SeatService scales for write throughput (SETNX parallelism, Redis connection pooling). Running them in the same service would mean a browse surge starves seat hold threads during the most critical moment: the exact instant of onsale.