Design Ticketmaster / StubHub

A ticketing platform sells seats to concerts, games and shows. On an ordinary day that is a quiet catalogue business: a few hundred thousand tickets across tens of thousands of events, browsed at a relaxed pace. Then a stadium tour goes on sale, and more than two million people arrive in the same minute for 60,000 seats.

The rest of the design follows from that mismatch. Demand is forty times supply, everyone arrives at once, and every seat is unique. Two people must never walk away holding the same seat, but you also cannot make two million people fight over database rows directly. You have to control how many people are shopping at any moment, then make each seat claim cheap, atomic and temporary until payment succeeds.

Size for the worst day, not the average one. Assume a stadium on-sale with 60,000 seats, 2.5 million people in the queue, and buyers taking about 3.2 tickets per order.

Look at the gap between 125,000 queue checks a second and about 300 hold attempts a second. The waiting room exists to turn the first number into the second. If you let all 2.5 million people reach the seat map directly, the inventory service would see hundreds of thousands of hold attempts a second for the same few thousand good seats, nearly all of which would fail.

The seat-picking endpoints require an admission token. Without one, the request is rejected at the edge before it reaches any service, which is what keeps the waiting room meaningful.

Traffic meets the CDN and edge first. Event pages, venue maps and static assets are cached there, and the edge checks tokens: requests to the booking API without a valid admission token for that event never reach the origin.

For a high-demand event, the waiting room issues each arrival a signed queue token and stores a compact record of their place. An admission controller decides how many people to let through per minute, based on how many shoppers are currently active and on load signals from the inventory service. Admitted users get a short-lived admission token and go to the seat map.

The inventory service owns the truth about every seat. Each event's seats live on one shard of a relational database, so all writes for an event go to one primary and can use ordinary transactions. Availability for seat maps is published to a cache every few seconds; holds always go to the database. When a hold turns into a purchase, the booking API calls payment, and on success converts the hold to sold and writes tickets in one transaction.

A stadium map is a large, static drawing that changes only when the venue is reconfigured, so it is served from the CDN as a vector file. What changes is which seats are free. The inventory service publishes a bitmap per section, one bit per seat, into the availability cache every two to five seconds. A 60,000-seat venue fits in under 8 KB, so the client can fetch the whole event's availability in one cheap request and colour the map locally. The map may be a few seconds stale; the hold call is what checks the real state.

The naive version reads the seat, checks it is available in application code, then writes "held". Two requests that read at the same moment both see "available" and both write. Wrapping it in a transaction at the default isolation level does not help either, because both reads succeed before either write. You need the check and the claim to be one atomic operation on the database.

Each seat row is locked only for the instant the update touches it. If two shoppers race for 112-K-14, one update wins and the other sees the row no longer matches and returns zero rows for it. The loser's transaction rolls back its other seats too, so a buyer never ends up with half of a pair. The service then answers 409 with the seats that went, in milliseconds, and the client suggests nearby alternatives.

Notice the second half of the condition: a hold whose held_until has passed counts as available. That is lazy expiry. No background job has to release seats on time for correctness. A sweeper still runs every few seconds to flip expired holds back to available so the seat map shows them, but if the sweeper stalls, the seats are still claimable.

Payment is authorised before the seats change to sold, and captured only after they have. The conversion is another conditional update: state = 'sold' where hold_id matches and the hold has not expired. If the buyer took too long and someone else claimed the seats after expiry, the update finds nothing, and the authorisation is voided so the buyer is never charged for seats they do not get.

To make the race rare rather than routine, the hold window shown to the buyer is slightly shorter than the one stored. The client counts down from seven and a half minutes while the database allows eight, which absorbs payment latency at the edge of the window.

When a buyer asks for "two seats together in price level P2", the service must pick seats without making every request fight over the same best ones. Order candidate seat blocks by quality, and claim with SELECT ... FOR UPDATE SKIP LOCKED over a short candidate list, then run the same conditional update. Skip-locked means a request that finds the top block being claimed by someone else moves to the next one instead of waiting, which spreads concurrent requests across the section.

A standing area with 8,000 places has no seat rows to claim, just a count. A single counter row for the section would serialise every hold for it. Split the section into allocation buckets, say 32 rows of 250 places each, and let each hold pick a random bucket with remaining capacity and decrement it with a conditional update. Contention drops thirty-two fold, and the total can never go below zero because each bucket checks its own count.

A lock per seat in Redis is a popular answer. It is fast, but it adds a second place where "who holds this seat" is recorded, and the two can disagree after a failover or a client pause. If the database is already the source of truth and each event fits on one shard, the conditional update gives you the same atomicity with one system instead of two. Use Redis for what it is good at here: the availability cache and the waiting room counters.

People who arrive before the on-sale opens are all equally early, so ordering them by arrival rewards bots that refresh fastest. Instead, give everyone who joins before the start a random position within that early group, then queue later arrivals in order behind them. Each queue token records the event, the user, the join time and the random value, signed so the client cannot change it. Position estimates are computed from counters of tokens issued and admitted, which means a status check is a signature check plus two counter reads, cheap enough at 125,000 a second.

The admission controller works like a rate limiter with feedback. It targets a number of active shoppers, about 10,000 here, and admits more as shoppers finish or their admission tokens expire. If hold latency rises, it slows admission. When inventory runs out, it tells everyone remaining that the event is sold out, rather than letting them wait for nothing.