Design Ticketmaster: event ticketing

Step 1

Requirements: functional and non-functional

The functional core:

• Browse seat availability for an event.
• Hold a seat: a temporary, exclusive reservation while the buyer checks out.
• Purchase: convert a hold into a sale after payment.
• Expire holds: release a seat if checkout is abandoned.

Out of scope (say it): payment internals, pricing, recommendations, resale.

The non-functional shape is the inverse of a feed:

The defining fact: a single seat is a unique, contended resource, and selling it twice is unacceptable. That forces strong consistency on the seat, and the onsale spike (a flood of buyers for scarce seats) forces a way to admit that flood without melting the inventory store.

Maps to S2 (requirements) and S1 (consistency over availability for inventory).

Step 2

Estimation: the numbers that bound the design

Maps to S2 (capacity estimation, spike not steady-state).

Step 3

API: hold then purchase

The two-step hold-then-purchase is the heart of it: holding gives the buyer exclusive time to pay without locking the seat forever, and purchase is the idempotent commit. Browsing is a separate, cacheable read.

Maps to S5 (API design): a reservation with a TTL, an idempotent commit. See the API cheat sheet.

Step 4

Data model and store choices

Event(id PK, name, onsale_at, venue_id)
Seat(id PK, event_id, section, status=available|held|sold, held_by, hold_expires_at)
Hold(id PK, seat_id, user_id, expires_at)
Order(id PK, seat_id, user_id, status, idempotency_key)

invariant:  a seat is held_by / sold to AT MOST one user at a time

stores
  Seat inventory .. the contended write hotspot; needs ATOMIC updates   -> relational (row locks) / strongly-consistent
  Waiting room .... a fair queue of users waiting to enter onsale        -> a queue / token service (Redis)
  Orders .......... durable record of sales                              -> relational

Maps to S3 (store from access patterns: atomic claims) and S4 (the hotspot is contention, not volume). See the data-stores cheat sheet.

Step 5

High-level architecture

Two guards in front of one consistent store. The waiting room meters the onsale flood into a rate the system can serve, admitting users in fair batches. The inventory service performs the atomic hold and sale against the strongly-consistent inventory store. A hold-expiry worker returns abandoned seats to available, and purchase calls out to the payment provider. The waiting room protects throughput; the atomic claim protects correctness.

Maps to S7 (architectural styles) and S6 (atomic claims, queues, backpressure).

Step 6

Deep dive A: high-contention inventory, no double-booking

The correctness core. Thousands of users try to grab the same seat at the same instant; exactly one must win, and the rest must cleanly lose. The answer is an atomic claim, never a read-then-write.

the bug: check-then-set (NOT atomic)
   if seat.status == available:   # two requests both read "available"
       seat.status = held          # both write "held" -> DOUBLE BOOKED

the fix: one atomic conditional update
   UPDATE seat
      SET status='held', held_by=:user, hold_expires_at=now()+2min
    WHERE id=:seat AND status='available'      <-- the guard
   rows_updated == 1 ?  you got it
   rows_updated == 0 ?  someone else won; pick another seat

   the database serializes writes to the row, so exactly one of the
   thousand concurrent updates sees status='available' and wins.

Maps to S6 (atomic operations, optimistic concurrency) and S9 (fail closed on the claim).

Step 6 · continued

Deep dive B: the onsale spike and the waiting room

Atomicity makes each claim correct, but a million simultaneous claims would still flatten the inventory store. The virtual waiting room turns a flash flood into a managed stream, and gives fairness as a bonus.

without a waiting room
   1M users hit POST /holds at 10:00:00 -> the inventory DB melts,
   everyone sees errors, and it is unfair (loudest client wins)

virtual waiting room
   - at onsale, users enter a QUEUE (a token with a position)
   - the system admits users in batches at a rate the inventory
     store can actually serve (e.g. N per second)
   - admitted users get a short-lived token to attempt holds
   - everyone else waits, sees their position, and is admitted in order

effect
   - smooths the spike into a steady, serveable flow (backpressure)
   - fairness: first-come-first-served, not first-to-retry-hardest
   - load shedding happens politely in the queue, not as 500s

Maps to S9 (load shedding, backpressure) and S4 (protect the hotspot). See the resilience cheat sheet.

Step 6 · continued

Deep dive C: holds, expiry, and purchase

A hold gives the buyer time to pay without locking the seat forever. The subtlety is the race between expiry and purchase, which must never let a seat be both released and sold.

hold lifecycle
   available --hold--> held (TTL ~2 min) --purchase--> sold
                          |
                          +-- TTL elapsed / cancel --> available

expiry without a race
   - do NOT trust a background sweeper alone to flip held->available
   - the atomic guard already encodes it:
       a hold is only valid WHERE status='held' AND hold_expires_at > now()
   - purchase: UPDATE ... SET status='sold'
               WHERE id=:seat AND held_by=:user AND hold_expires_at > now()
       -> if the hold expired, purchase fails cleanly (rows=0)
   - the sweeper is just cleanup; correctness lives in the guarded update

payment
   - charge via the payment provider with an idempotency key
   - payment fails -> release the hold; never a sold seat with no payment

Maps to S6 (atomic state transitions) and S9 (no expiry-vs-purchase race).

Step 7

Reliability & failure design

Correctness is non-negotiable, so every seat transition is a fail-closed atomic update: when in doubt, you did not get the seat. Availability is bought differently, by the waiting room metering load so the consistent store is never asked for more than it can do. Payment is idempotent and a failed charge releases the hold, so the system never ends in a sold-but-unpaid or paid-but-unsold state.

Maps to S9 (designing for failure): fail closed on the seat, shed load at the door.

Step 7 · continued

Observability & operability

• The invariant as an SLI: double-booked seats = 0. Any non-zero value is a sev-1, the same way a ledger imbalance is for payments.
• Onsale health: waiting-room length and wait time, admit rate, and hold success rate. These tell you whether the metering is right.
• Inventory store load: write latency and contention on hot seats; the signal that the admit rate is too high.
• The three pillars: metrics for double-booking and queue depth, traces across hold and purchase, structured logs keyed by seat and hold id.
• Alert on correctness and the spike: page on any double-booking, on inventory write-latency burn, and on queue blowout, not raw CPU.

Maps to S10 (observability). See the observability cheat sheet.

Step 8

Trade-offs along the six core axes

The whole design is two guards around one truth: a waiting room so the flood arrives at a serveable rate, and an atomic conditional update so exactly one buyer ever wins a seat. Everything else, holds, expiry, payment, hangs off that. Say it and the boxes follow.

Maps to S1 (the six core trade-offs) and S12 (present and defend).