Design Ticketmaster — Event Booking & Seat Reservation

Design a ticket booking site supporting event browsing, search, and seat-level booking, with strong guarantees against double-booking and the ability to handle traffic spikes from high-demand on-sales. Requirements Functional: browse and search events; view a venue seat map with live availability; reserve specific seats; complete payment; receive a confirmed ticket; cancellation and refund within policy. Non-functional: no double-booking under concurrency (strong consistency on the booking write path); search latency p99 < 500 ms; read-heavy workload (~100:1 read-to-write); handle 10M concurrent users on a marquee on-sale. Core entities: Event, Venue, Seat (seat_id, event_id, section, row, number, status), Reservation (seat_id, user_id, expires_at), Booking (reservation_ids, payment_status), User, Performer. Notes The classic interviewer-expected approach for double-booking prevention is a distributed lock with TTL rather than a long database row lock. On seat selection, acquire a short-lived lock (5-10 minutes) per seat_id in Redis using SET NX EX; if the lock holds, mark the seat reserved in the database with an expires_at. On payment confirmation, transition reserved → booked inside a relational transaction and release the lock. On TTL expiry without payment, a sweeper transitions the row back to available and the lock auto-releases. This split — Redis for the optimistic short-lived hold, relational storage for the durable booking — is what the round expects. A pure database-level row lock works for small venues but does not scale and creates long-held transactions during checkout. Search is layered: PostgreSQL is the source of truth for event metadata; Elasticsearch (or OpenSearch) holds the searchable projection, synced via change-data-capture for fuzzy and typo-tolerant queries. Cache popular search results at the CDN / edge for unauthenticated browse traffic. For marquee on-sales (Taylor Swift class), the standard pattern is a virtual waiting room: users connect over Server-Sent Events or WebSocket, get a position in a Redis-backed queue, and only the front N are admitted to the booking interface at a time. This caps load on the booking service to its provisioned capacity and keeps the rest of the site responsive. Caching is aggressive on the read path: per-event seat map snapshot in Redis (invalidated on every booking write), CDN for static event pages, materialized views for popular search facets. The write path stays uncached and serialized through the relational primary. For leveling: an E4-equivalent is expected to produce the API + data model + a workable booking flow. E5 is expected to push into double-booking prevention with the lock + TTL pattern and to discuss the search optimization. Staff+ goes deeper on the waiting-room mechanics, multi-region data placement, and how to handle partial payment failures mid-booking. Preparation Pre-draw the canonical block diagram (clients → CDN → API gateway → booking service + search service + reservation cache + relational primary + analytics outbox) and time yourself to under three minutes. Memorize the booking state machine: available → reserved (lock + TTL) → booked (payment confirmed) → canceled / refunded. Be able to enumerate the failure transitions (lock expires, payment fails, partial payment, race between two users on the same seat). Drill the two deep-dive prompts the round commonly opens with: "walk me through what happens when two users click the same seat at the same time" and "a million people just hit the on-sale button — what protects the booking service." Carry concrete numbers: a 60k-seat stadium yields a small relational row count per event but enormous read pressure; the QPS arithmetic should be on the board before the deep dive begins.