Design Ticketmaster

A stadium tour goes on sale at 10am. Two million fans want sixty thousand seats, and each fan does not want "a seat", they want G5 in the floor section, next to their friend in G4. Every seat is its own tiny auction, and it closes in milliseconds.

Watch one fan get from the line to a ticket.

The picture is two systems with very different promises. The top half, the seat map, may be a little out of date, and it takes nearly all the reads. The bottom half, the hold, must be exact for every single seat, and it takes very few writes. Most of this page is about keeping those two promises separate.

If you have read IRCTC tatkal, here is the difference that matters. There, seats in a class are interchangeable, so the whole fight is over one number per train. Here the fan chooses seat G5, so every seat is its own row and its own race, and a group of seats has to be won together. The same problem shows up when you book two seats next to each other for a first day, first show at a cinema, or tickets for an IPL final.

A few words used all through this page:

• A hold takes seats off sale for a few minutes while one fan pays. If they never pay, the seats go back.
• The seat map is the picture of a section with every seat coloured free, held or sold.
• The waiting room gives each fan a place in line before they may shop, like the token machine at a bank.
• An on-sale is the moment a popular event's tickets go on sale, announced in advance.

Step 1: Understand the problem#

Ask about the seats before you ask about the traffic. Whether a fan picks a specific seat or just "two tickets in the upper tier" decides what the contended thing is, and everything else follows from that.

What you are building, and what you cut#

Back of the envelope#

A small version first. A 60,000 seat stadium, four tickets per order, is 15,000 orders. If it sells out in ten minutes, that is 1,500 checkouts a minute, which is 25 a second. That number is small. The people trying to become one of those 25 a second are not. (The back of the envelope chapter covers the method.)

Read the first and third rows together. The writes that matter are a few dozen a second. The waiting room and the seat map cache carry everything else, and the hold service never sees the crowd at all.

Step 2: Propose the high level design#

The API#

Four calls. The hold is the one that matters, and its 409 is designed as carefully as its 201.

{
  "seats": ["FLR-G4", "FLR-G5"],
  "admissionToken": "eyJ...",
  "idempotencyKey": "h_5e1a..."
}

{ "section": "FLR", "count": 4, "together": true, ... }

{ "paymentToken": "...", "idempotencyKey": "c_77b0..." }

The admission token comes from the waiting room and is checked on every hold, so a fan cannot skip the line by calling the API directly. The idempotency keys mean a double tap on a bad connection returns the first hold instead of a second one (idempotency keys shows how).

The data model#

Two tables in the seat store, both keyed by event first, so every row for one show sits on one database machine and a hold for several seats is one local transaction.

The whole system on one whiteboard#

Figure 1 is the picture at the top, laid flat, with the CDN and the job that rebuilds the seat map added.

Walking Figure 1:

1. Fans join the line. The waiting room hands each one a signed token with a position and does no other work, so it can take the whole crowd. The event page itself comes from the CDN and never reaches us.
2. The room admits fans at the rate checkouts finish, about 1,500 a minute in the napkin above, and only an admitted fan's token is accepted by the API.
3. The fan opens a section. Its map comes from the cache, rebuilt every couple of seconds from a replica of the seat store by the map builder. It may be a little behind, on purpose.
4. The fan taps two seats and asks to hold them.
5. The hold service claims both seat rows in one transaction, each only if it is free or its old hold has run out. Both rows change, or the transaction is rolled back and the fan gets a 409 with a fresh map.
6. Checkout charges the card through the payment gateway, with the seats already held. Starting payment moves the hold to paying and extends it once.
7. Payment clears, the seats become sold and the order and tickets are issued.

There is no box for expiring holds. That is deliberate, and the first deep dive shows why.

Step 3: Design deep dive#

Holding G5, and only G5#

The contended thing is one seat row. Three fans can want G5 at once, and the claim has to pick exactly one of them without a slow lock and without a background job.

Try it. In "seat by seat", hold for Rahul and then for Priya and look at G6. In "all or nothing", do the same, then move the clock past 10:08 without paying, and hold for Priya again.

Two things the widget shows. First, a group of seats is one claim: half a pair is worse than nothing, because the fan cannot use it and nobody else can buy it for 8 minutes. Second, expiry needs no job. A sweeper can still run to tidy rows and update the seat map, but a late sweeper only delays the tidying, never a sale. That is the difference from a sweeper that is part of correctness, like the tatkal one.

The race itself is the classic lost update, settled the same way as tatkal's single row: check and change in one statement, and let the row count decide. What is new here is that one statement now touches several rows.

What happens when time runs out in the middle of a payment? The fan has typed their card number at 10:07 and the gateway answers at 10:09. Starting checkout moves the hold to paying and pushes held_until out once, by enough to cover a slow payment. And a hold whose payment outcome is unknown is never released: the system asks the gateway about it by its reference, then sells the seats or frees them. That is the rule from UPI payments, where a timeout means "unknown", not "failed".

The seat map is allowed to lie#

Two million people refreshing a seat map would bury the seat store if every refresh read it. So the map has a different promise from the hold, and saying that out loud is half of the answer.

So a fan can tap a seat that shows as free and get "that seat just went". That is not a bug. The map promised "roughly", the hold promised "exactly", and the 409 is where the two meet. Deciding consistency per feature like this is the idea in strong vs eventual consistency.

Held is not sold#

The waiting room works like the tatkal queue: signed positions, and admission at the rate the booking path can serve. Two things are different here, and both come from holds.

First, admission follows checkouts, not seats. An admitted fan spends minutes choosing and paying, so the room admits roughly as many fans as are leaving checkout each minute, about 1,500 at the napkin's numbers. Admit faster and fans pile into a store with nothing left to hold. Admit slower and seats sit unsold.

Second, the moment every seat is held is not the moment the show is sold out. A held seat comes back if its fan does not pay, and some always do not. So the line must not tell fan number 200,000 "sold out" while thousands of seats are only held. It says "everything is held right now, seats may come back", keeps admitting slowly as holds lapse, and switches to sold out only when held seats reach zero.

Break it#

The front row case is worth saying unprompted. It looks like a database problem and it is not: the seat store handles a few hundred tiny transactions a second easily. The waste is the retry loop on the client, and the fix is a better 409 and letting the server pick seats.

Trade-offs#

The level bar#

One moment from this round, answered three ways. Pick the one you think is staff level before the labels appear. (What changes at senior and staff explains the gap.)

Then run the question cold, with a 45 minute timer and no notes, and score the run on the five things this question is really testing.

Interview replay#

Checkpoint#