Design the backend for a reserved-seating ticket platform (think a popular concert or long-distance train booking app) where every buyer picks a specific seat off a live seat map. The hard part is contention: the moment a hot event opens, tens of thousands of people race for the same few hundred good seats, and no seat may ever be sold twice.

Operating context. A venue or vehicle has a fixed seat inventory per event — from a 200-seat theatre to a 60,000-seat stadium. Most events are quiet, but a few on-sale moments spike hard: expect up to 50,000 concurrent shoppers hammering one event, a browse/read load around 80,000 RPS, and a hold/confirm write load bursting to 5,000 RPS against a single event's inventory. A shopper selects one or more seats, gets a short-lived hold while they enter payment, then confirms. Holds expire automatically if payment does not complete inside the window. When a section sells out, buyers may join a waitlist and be offered released seats.

Out of scope. The payment processor internals (assume a third-party gateway you call), venue seat-map authoring/CMS, pricing and promo-code engines, fraud/bot mitigation, and post-purchase ticket delivery (PDF/wallet). Assume separate teams own those.

What to produce. A high-level architecture covering: the components and the request paths for browse-map, place-hold, confirm, and release/expire; the seat-inventory data model and how you partition it; how a hold is made atomic and given a TTL so an abandoned cart self-heals; how confirm turns a hold into a sale exactly once even under a retried/duplicate request; how you prevent oversell under 5,000 write RPS on one event; the waitlist and seat-release flow; and how the seat map a shopper sees stays fresh. Sketch the major components and the flow between them; we probe specifics in checkpoints.