Ticketmaster-Style Seat Booking Design

Phone-screen system design: design a Ticketmaster-like seat booking flow with a heavy focus on preventing double booking, API semantics, frontend seat-map behavior, and user experience during contention. Requirements Design a seat-booking system for a Ticketmaster-like product. Functional requirements: Users can browse an event seat map and see available / held / sold seats. Users can select seats and attempt checkout. The system must prevent two users from successfully booking the same seat. APIs should return enough state for the frontend to update the displayed seat map. Scale / contention constraint: popular events can have many users competing for the same seats at the same time. Design decision points: Pessimistic holds vs. optimistic checkout-time conflict detection. Hold TTL and abandoned-cart cleanup. Seat inventory storage model and transaction boundary. API response shape when a seat becomes unavailable during checkout. Notes Interviewers focus strongly on double booking and UX. Do not stop at a database uniqueness constraint; explain what the user sees when another buyer wins the race. A practical design uses short-lived holds, idempotent checkout requests, and a single transactional commit that converts held seats to sold seats. Seat holds need ownership checks and TTL recovery. Multi-seat holds should be all-or-nothing, commonly via a single database transaction or an atomic Redis Lua script, so a user does not get a partial adjacent-seat cart. Frontend state matters: distinguish available, selected-by-me, held-by-other, and sold so the seat map can recover from conflicts without a confusing full refresh. Integration failures can still create apparent double bookings if downstream ticket issuance ignores a failed inventory transition; the booking response must be authoritative. Preparation Whiteboard the state machine available -> held -> sold plus held -> available on TTL expiry, including idempotency keys for checkout retries. Drill the hot-seat race: two users request the same seat, one wins the hold, the other gets a conflict payload that updates only the affected seat map cells. Prepare a scale path from single-node SQL row locks to Redis holds, virtual waiting room admission control, and per-event partitioning for marquee events.