Design Ticket Booking

A band announces one stadium show. Tickets go on sale Friday at 10:00. At 9:59 two million fans are sitting on the page, and there are 50,000 seats. Within the next few minutes, each seat must go to exactly one person, every person who pays must get a seat, and the site must not fall over while it happens.

Interviewers like this question because the normal day is easy and the hard parts are sharp: two people clicking the same seat in the same second, a huge spike at one moment, and a payment step that takes minutes while the seat stays reserved. The steps follow A Framework for Any Design. Try each "Your turn" box before you read on.

#Clarify the problem

• Functional: browse events and a live seat map; pick seats and hold them for a few minutes; pay and receive tickets; release seats that are not paid for.
• Non-functional: no seat is ever sold twice (strong consistency on inventory); a paid order always ends with tickets or a refund; the site stays up when demand is 80 times the supply; seat holds last 10 minutes.
• Out of scope: resale, dynamic pricing, event creation, ticket scanning at the door.

#Estimate the scale

Do the normal day, then the on-sale.

• Normal orders: 5 million a month ÷ 2.6 million seconds ≈ 2 orders a second. Browsing is maybe 100 times that: 200 reads a second. One database handles it.
• Demand at the on-sale: 50,000 seats at about 2 per order is 25,000 orders. Two million fans for 25,000 orders is 80 fans per order. Most of them will leave with nothing, and the system has to tell them so quickly.
• Without any control: if two million fans refresh the seat map every 5 seconds, that is 2,000,000 ÷ 5 = 400,000 requests a second, all aimed at one event's 50,000 rows.
• Storage: 100,000 events a year × 2,000 seats × 100 B = 20 GB of seat rows; 60 million orders × 1 KB = 60 GB. Size is not the problem; contention is.

#Define the API

POST /events/{id}/queue                     join the line
  200 { "ticket": "signed...", "position": 48213 }
 
GET  /events/{id}/queue/status              cached for 1 s at the CDN
  200 { "admitted_up_to": 40500, "sold_out": false }
 
POST /events/{id}/queue/pass                exchange an admitted ticket
  200 { "pass": "signed...", "expires_in": 900 }
  403 Forbidden     your number has not been reached yet
 
GET  /events/{id}/seats?section=C           needs a pass
  200 { "seats": [ { "id": "C-12", "status": "available", "price": 9500 }, ... ] }
 
POST /events/{id}/holds                     needs a pass
  body: { "seat_ids": ["C-12", "C-13"] }
  201 { "order_id": "9001", "held_until": "10:31:04" }
  409 Conflict      one or more seats are taken; body lists them
 
POST /orders/{id}/pay    Idempotency-Key: 9001
  200 { "status": "paid", "tickets": [...] }
  402 Payment Required   card declined; the hold stays until it expires
  410 Gone               the hold expired before payment started
 
DELETE /orders/{id}                         release a hold early

The API decision worth arguing is the waiting-room status. Each fan's ticket carries their number, so the server publishes one number per event: "admitted up to 40,500". Every fan gets the same tiny response, so a CDN caches it for a second and absorbs nearly all 200,000 requests a second. The browser works out its position by subtraction.

Make pay safe to retry with an idempotency key; the order id is a natural one. A fan who double-clicks "Pay" on a slow connection must not be charged twice.

#Model the data

seats
  event_id     BIGINT
  seat_id      VARCHAR(16)     -- "C-12"
  section      VARCHAR(8)
  price_cents  INT
  status       VARCHAR(10)     -- available | held | sold
  order_id     BIGINT NULL     -- who holds or owns it
  held_until   TIMESTAMP NULL
  PRIMARY KEY (event_id, seat_id)
 
orders
  order_id     BIGINT PRIMARY KEY
  user_id      BIGINT
  event_id     BIGINT
  status       VARCHAR(10)     -- held | paying | paid | expired | refunded
  amount_cents INT
  payment_id   VARCHAR(64) NULL
  created_at   TIMESTAMP

Access patterns: read the seats of one event or section, claim a few seats of one event at once, and turn an order's seats into sold. The claim must be all-or-nothing across several rows, which points to a relational database with transactions, partitioned by event_id when one machine is not enough. A key-value store can do single-row conditional writes, but not an atomic claim of two seats.

Hold the seat in the row, not in a database lock. A database lock is meant to last milliseconds; a fan takes minutes to pay. The hold is a business-level lock written as data, with its own expiry.

#High-level design

The design separates two crowds. The two million waiting fans only touch the waiting room. The 10,000 admitted fans reach the booking service, the only writer to inventory.

Step through a fan getting seats, a second fan losing a race, and a hold that lapses.

#Deep dives

Interviewers push on three things: stopping two buyers getting one seat, keeping the spike away from the database, and the gap between holding and paying.

#Preventing double booking

Two requests for C-13 arrive within a millisecond. Each, on its own, would read "available" and write "held". One of them must fail.

BEGIN;
UPDATE seats
   SET status = 'held', order_id = 9001,
       held_until = now() + interval '10 minutes'
 WHERE event_id = 77 AND seat_id IN ('C-12', 'C-13')
   AND (status = 'available'
        OR (status = 'held' AND held_until < now()));
-- rows changed = 2: COMMIT.  fewer than 2: ROLLBACK, report 409.
COMMIT;

Why this is safe: when two transactions update the same row, the database lets one go first and makes the other wait for its row lock. At the default read-committed level in databases such as PostgreSQL, the waiting update then re-checks its WHERE clause against the new row, sees held, and changes nothing. At repeatable read or serializable, the waiting update fails with a serialization error instead. Either way the second buyer does not get the seat; treat the error like a 409. Databases differ in these details (see transactions and isolation), so name the level and the behaviour you rely on. Two buyers grabbing overlapping seats in opposite order can deadlock; the database aborts one, which reports the seats as taken.

I would pick the conditional update: one round trip, and no lock held while anyone thinks. General admission changes the details, not the choice: see the follow-up questions.

#Surviving the on-sale spike

Adding servers does not solve this. The 50,000 seats live on one partition, and more booking servers only send it more conflicting writes. Instead, control how many fans reach the booking flow: a virtual waiting room.

• Join: each fan gets a number from a counter, inside a signed ticket. Numbers handed out before 10:00 are shuffled at 10:00, so sending a request at 9:59:59.999 gains nothing; after that it is first come, first served.
• Wait: the only thing polled is "admitted up to N", one cached number per event, so 200,000 polls a second cost almost nothing.
• Admit: a controller keeps at most 10,000 fans in the flow and raises N whenever an order completes or a pass times out. The database sees about 33 new fans a second, whatever the crowd size.
• Enter: an admitted fan gets a signed pass, valid for 15 minutes and tied to their account. The gateway checks the signature without any shared state.
• Stop: when no seat is available or held, tell everyone waiting it is sold out. A line of two million at 33 a second would take 2,000,000 ÷ 33 ≈ 60,000 seconds, about 17 hours, to drain.

Admitted fans read the seat map from a cache rebuilt about once a second. That is fine because the map is advice and the conditional update is the truth: a stale map costs a fan one 409, never a double sale.

#Paying and releasing holds

The gap between "held" and "sold" is where the bugs live.

• The hold must outlive the payment. If a hold lapses at 10:31:04 and the charge succeeds at 10:31:05, a second fan may already hold that seat. So when the fan presses Pay, move the order to paying and extend held_until past the longest the processor can take. Holds in paying are never swept.
• Confirm with a check. The sale is UPDATE seats SET status = 'sold' WHERE order_id = 9001 AND status = 'held', and it must change both rows. If it ever does not, refund the order automatically.
• An unknown payment result is not a failure. If the processor call times out, the charge may have gone through. Keep the order in paying, ask the processor for the result using the idempotency key, and only then sell or release. Design a Payment System covers this in depth.

#Bottlenecks and failures

At 10x, twenty million fans for one show, the waiting room absorbs it: 2 million polls a second for one cached number is a CDN problem, not a database problem. The booking side does not change, because the admission cap sets its load. For many on-sales at once, partition inventory by event_id so each big show has its own partition.

#What a strong answer sounds like

#Follow-up questions

#How would you handle general admission?

There are no seat rows, just a count per section, and every buyer decrements it with the same conditional update: SET remaining = remaining - 2 WHERE remaining >= 2. That one row is the hot spot, because every claim waits for the row lock. Split the count across, say, 10 rows and let each request try a random row that still has tickets, so ten claims can commit at once.

#How do you stop bots from buying everything?

One place in line per verified account, a challenge when joining, and a cap on tickets per order and per account.

#A group wants six seats together. What changes?

Offer "best available" instead of picking from the map: the booking service searches for six adjacent free seats and claims them with the same all-or-nothing update. If one was just taken, search again.

#Could you push seat changes to the map instead of polling?

Yes: send each hold and sale to the admitted fans viewing that section over server-sent events. It cuts 409s but adds 10,000 open connections and a fan-out per write. Since the claim is the truth, a map one second stale is harmless, so start with the cache and add push only if 409s are frequent.

#Why not hold the seats for 30 minutes to be kind?

Every minute of hold is a minute an abandoned seat is hidden from fans still in line. Ten minutes, extended only once payment starts, balances both.