01General admission — so no seat map at all?
Correct — there is no seat map: an event is a handful of ticket tiers (GA floor 5,000, GA balcony 8,000), each just a capacity count, so buying means taking N from a tier’s count, never picking a seat.
Premium preview
Design Ticketmaster for general-admission events — there is no seat map, only a fixed capacity count per ticket tier, and the system must sell tickets correctly under extreme flash-sale contention...
The requirements are open as a taste. From the numbers onward, the full guide opens in the app.
Do not only state requirements. Ask for them. Each card pairs the design constraint with a clarification question you can say out loud before drawing the architecture.
01General admission — so no seat map at all?
Correct — there is no seat map: an event is a handful of ticket tiers (GA floor 5,000, GA balcony 8,000), each just a capacity count, so buying means taking N from a tier’s count, never picking a seat.
02One tier per event, or several?
Several tiers per event: a buyer picks a tier and a quantity in one purchase, and when one tier hits zero the others keep selling — sold out is a per-tier state, not a per-event one.
03How many tickets can one person take?
Four tickets per user per event, enforced in the same atomic step as the purchase itself, so the same account on two devices cannot stack requests past the cap.
04Is the ticket mine when I click, or when I pay?
Clicking buy takes a hold: the tier count drops by N immediately and the buyer has 10 minutes to pay; if the hold expires or is abandoned, the count goes straight back on sale.
05Does everyone hit the buy page at once?
Buyers enter through a waiting room that admits in strict join order — refreshing or reconnecting keeps a position rather than granting a new one — and bot filtering runs at this door, before anyone touches inventory.
06What do refunds and transfers do to capacity?
A refund returns its quantity to the tier’s count, so a sold-out event can legitimately reopen; a transfer only changes the ticket’s owner and never touches capacity.
Out of scopeReserved seating and seat-map rendering (the seated Ticketmaster question) · Payment processing internals (the Payment System question) · Dynamic pricing and a secondary resale marketplace
01How bad is selling ticket 5,001?
Never oversell: GA capacity is a fire-code number, so the decrement is strictly atomic and the count can never pass below zero — this is the one unforgivable failure.
02What does fairness mean here?
Fairness is verifiable: buyers are served in queue-join order, and no refresh, second tab, or reconnect can improve a position.
03What load must checkout survive?
The on-sale minute is the design point: each purchase stays a fixed-cost atomic operation, so checkout latency does not grow with the size of the crowd.
04Must the count on screen be exact?
The remaining-count display is an approximation refreshed every few seconds; only the write-path counter is truth — that split lets millions watch without touching the hot key.
05Can one viral on-sale hurt other events?
On-sales are isolated per event: one stadium sale saturating its own queue and counters leaves every other event’s checkout untouched.
Real interviews probe far more than a tidy list. These are the scope questions that separate candidates who interrogate the problem from those who recite it.
Numbers, architecture diagram, API and data model, deep dives, expected topics, self-check, whiteboard starter, and common mistakes unlock inside the app.
Locked in the app
Locked in the app
Locked in the app
Locked in the app