Design ticket booking

At 10:00 the tickets for a stadium tour go on sale and a million fans press "Buy" for 50,000 seats. Most of the time a booking site is quiet; for a few minutes it faces a stampede where every request wants the same rows. Two promises matter: never sell a seat twice, and stay up long enough to sell the rest fairly. It follows the interview framework phase by phase.

1. The prompt

"Design Ticketmaster: users find events, view a seat map, pick seats, pay, and receive tickets. Popular events sell out in minutes."

The interesting part is the few minutes of an on-sale: correctness under extreme contention on a small set of rows, and a front door that doesn't fall over. If you've done D24 flash-sale checkout, this is its cousin with named seats instead of identical units.

2. Frame the problem

3. What it must do

1. A user can search and view events.
2. A user can see available seats and hold some while paying.
3. A user can pay and receive tickets.

Not now:

• A resale marketplace.
• Dynamic pricing.
• Venue management.

4. How well it must do it

5. Numbers that change the design

6. The nouns

• Event: venue, time, details.
• Seat: per event, with a status.
• Booking: a user's claim on some seats.
• Queue ticket: a fan's place in the waiting room.

events    event_id, venue_id, starts_at, name, on_sale_at
seats     (event_id, seat_id) → section, row, number, price, status: available | held | sold,
          booking_id, hold_expires_at                        (partitioned by event_id)
bookings  booking_id, user_id, event_id, seat_ids, status: pending | confirmed | expired,
          payment_id, created_at
queue     (event_id, position) → user_id, admitted_at, token

7. The contract

GET  /v1/events?query=…               → search results
GET  /v1/events/{id}                   → details (cached)
GET  /v1/events/{id}/seats             → seat map (cached for a second or two)
POST /v1/bookings {event_id, seat_ids} → 201 {booking_id, hold_expires_at} | 409 seats taken
POST /v1/bookings/{id}/pay {payment_token}   Idempotency-Key: …   → confirmed

The user comes from the session, never the body. During an on-sale, booking calls also need a valid waiting-room token.

Data flow: (1) fans join the waiting room → (2) admitted at a set rate with a token → (3) view the cached seat map → (4) hold seats with a conditional update → (5) pay → (6) confirm: seats sold, booking confirmed.

8. First working version

A web service and one database with events, seats and bookings tables.

8.1 Browsing

Event pages and search read from the database; the seat map lists seat statuses for the event.

8.2 Booking

Version one reads the seat, checks it's available, then writes the booking. Run the simulator in section 13 to see how often that sells a seat twice.

8.3 Paying

Charge the card, then mark the seats sold.

9. Make it hold up

9.1 Never selling a seat twice no double booking

9.2 Holding seats during payment unpaid holds return

Paying takes a minute or two, so the seat is held with an expiry (say 10 minutes) instead of sold. If payment succeeds, the booking and the seats become confirmed in one transaction, which must still check that the hold is theirs. If the user leaves, the hold simply expires: the conditional update treats an expired hold as available, so no cleanup job is needed for correctness (a sweeper can tidy rows for display).

One edge needs care: a payment that succeeds just after the hold expired and someone else took the seat. The confirm step finds the hold isn't theirs, and the system refunds automatically. Keep the hold a little longer than the payment page's own timeout so this is rare.

9.3 Surviving the on-sale stampede survive spikes

• Virtual waiting room: before the sale, users join a queue (often at the CDN edge). At on-sale they are admitted in order at the rate the booking system can serve, each with a signed token valid for a few minutes. Everyone else sees their position, not an error page.
• Why it helps correctness too: admitted users see a fresh seat map and compete with a few hundred people, not a million, so far fewer clicks fail with "seat just taken". It also stops bots from simply out-refreshing people.
• Protect the rest: rate-limit per user and per token (Design D02), shed load with clear messages, and keep the browsing side cached so it stays up.

9.4 Seat maps and search fast browsing

The seat map is read constantly and changes constantly during a sale. Serve it from a cache refreshed every second or two (slightly stale is fine, because the conditional update is the real check), or push updates over Server-Sent Events. Event search goes to a search engine fed from the events database by change data capture; event pages are cached at the CDN.

9.5 Paying exactly once no double booking

Payment calls carry an idempotency key derived from the booking id, so a retried request (a double click, a timeout) never charges twice; the provider returns the first result. If the confirm step fails after the charge succeeded, a background job reconciles: it finds charged-but-pending bookings and confirms or refunds them (Design D16).

9.6 Partitioning and contention survive spikes

Partition seat data by event so a hot event doesn't slow others. One huge event still lives on one partition, which is fine at ~85 bookings a second; split by section if it isn't. Offering best available (the server assigns seats) instead of pick-your-seat spreads demand across rows and cuts conflicts sharply.

9.7 The whole design after the deep dives

One fan's on-sale, from the queue to a confirmed ticket.

10. Interviewer follow-ups

Variation: booking a stay for several nights

A hotel or holiday-rental version ("book listing 88 from 12 to 15 March") changes what can clash. A seat is one thing; a stay is a range of nights, and two bookings clash when their ranges overlap, even if they start on different days.

The rest of the seat design carries over: a short hold while the guest pays, released when it expires, and idempotent payment. Two things are new. Hosts may approve requests, so a request holds the nights for, say, 24 hours until the host answers. And hosts also list the same place on other sites; calendars imported from those sites are hours old, so a clash is still possible. Have a clear policy for it (cancel the later booking, rehouse the guest, charge the host).

Read more: PostgreSQL's documentation on exclusion constraints.

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Hold length: long holds are kind to slow payers but lock seats away from others during the rush; short holds frustrate people mid-payment.
• Pick-your-seat vs best-available: picking creates contention on the same seats; assigning spreads the load.
• A waiting room: fair and protective, at the cost of making people wait.
• The database as the only judge: caches may be stale; the conditional update never is.

What we'd watch:

• Double bookings (must be zero).
• 409 rate.
• Hold-to-sold conversion.
• Admission rate and queue length.
• Booking write p99.

At 10×:

• Partition hot events by section.
• Best-available by default.
• A longer queue rather than a faster door.

Common mistakes:

• Check-then-write booking.
• Selling seats before payment, or holding them forever.
• Trusting the cached seat map.
• No plan for the on-sale crowd.
• Non-idempotent payment calls.

13. Try it, check yourself, read more

100 seats, fans arriving in a 10-second burst. Each fan picks one of the best seats that look free on their (possibly stale) seat map and tries to book it, retrying up to three times. Red seats were sold twice.

The waiting room admits 25 fans a second, who see a seat map 0.3 s old; without it, everyone arrives at once and sees a map about 3 s old. A booking's check and write are 50 ms apart.