Ticket booking — a full worked answer

Assumptions: global, but each event belongs to one venue with a fixed, known number of seats: typically thousands, not millions. Traffic is extremely spiky. An event goes on sale at a fixed moment and receives most of its demand in about sixty seconds. Payments happen through a provider. Reads massively outnumber writes even during a sale, because most people are looking rather than committing.

First question, which decides how much locking I need: are seats specific and numbered, or is it general admission where only the count matters? Numbered seats mean the contended resource is one row per seat and uniqueness is naturally enforceable; general admission means a single counter that everyone contends on, which is a harder concurrency problem. I will assume numbered seats, as the prompt says.

Second question: do we hold a seat while the user pays, and for how long? A hold makes inventory unavailable to everybody else, so the window length is a direct business tradeoff. It also introduces expiry, which is a whole subsystem. I will assume yes, 10 minutes.

Scope: browse events and seat availability, hold a seat, pay, confirm. Out of scope: pricing and dynamic pricing, seat recommendations, refunds and resale, and fraud. I will note, though, that a sale like this attracts bots, and the queueing mechanism is partly an anti-bot control.

Actors: the buyer, the event organiser who defines inventory, the payment provider, and the system, which decides who gets into the sale, when a hold expires, and what to do about a payment that lands after a hold has already lapsed.

Track the seat, not the user, because the seat is the contested resource. Its life: available → held → paid → confirmed → possibly released back to available.

Failure branches, which are the design. At held: two users try to hold the same seat in the same millisecond. One must succeed, enforced by a conditional update or a unique constraint, never by check-then-write. At held: the user abandons the checkout, so the hold must expire, and the mechanism matters. A background job sweeping for expired holds can lag. I prefer holds that carry an expiry timestamp checked on read, so an expired hold is released at once even if the sweeper is behind. At held: the hold expires while the user is mid-payment. This is the nastiest branch, because their money is about to move for a seat they no longer have.

At paid: the payment succeeds and the confirmation write fails. This is the classic distributed transaction failure, and the answer is ordering plus reconciliation: authorise the payment while the hold is valid, confirm the seat, then capture. If the confirmation cannot be written, void the authorisation, which is far cheaper and cleaner than refunding a completed charge.

At paid: the payment provider times out and the client retries. Without an idempotency key, that is two charges. At confirmed: the event is cancelled, so every seat needs a bulk release-and-refund path.

And one the system must spot on its own: a user who holds seats, never pays, and does it repeatedly at scale is a bot denying inventory to real buyers. Holds need per-user limits, which is a design requirement, not a policy afterthought.

The shape is the story. A 50,000-seat event with 500,000 people trying to buy in the first minute. That is not "high traffic", it is a wall: roughly 100,000 requests per second arriving in a burst against a system whose steady state is a few hundred.

Look at what those requests are. The large majority are page loads and availability checks, which are reads. Actual hold attempts might be 20,000 per second at the very start, and successful claims are capped at 50,000 total, ever, for this event, because that is how many seats exist. The contended write path processes at most 50,000 operations in the entire sale.

That number changes the design. The write path is not a throughput problem: 50,000 writes in total is nothing. It is a contention problem: 20,000 attempts a second aimed at a few thousand rows that are rapidly being taken. Almost every one of those attempts must fail, quickly and cheaply.

Reads: 100,000 requests a second for mostly identical data (the event page, the seat map). That is close to an ideal caching problem, because everyone wants the same bytes at the same moment.

Storage: 50,000 seats per event at a couple of hundred bytes is 10 MB per event. Even a hundred thousand stadium-sized events a year is about a terabyte, and most venues are far smaller. Storage is not a concern.

So the hard part here is contention, not volume: rejecting the ~90% of attempts that must fail without letting them touch the database at all. The second hard part is keeping the small exact part exact under that pressure.

The first move is drawing the line between the stale tier and the exact tier, and keeping the exact tier as small as possible. Everything about browsing (event pages, seat maps, prices) is served from a CDN and a cache with a short TTL. Justified by the read numbers: everyone requests identical bytes simultaneously, so the hit rate is near perfect. The seat map being a few seconds stale is fine and I would say so explicitly, because a user clicking a taken seat is a normal, cheap rejection.

A waiting room in front of the sale. At on-sale, users are given a queue position and admitted at a controlled rate. This component does more than any other here. It converts an uncontrolled 100,000-per-second burst into a steady, known rate the booking path can serve. It makes the experience honest (a position and an estimate rather than an error). And it is the main anti-bot control. Justified directly by the burst shape from Stage 3.

The claim itself, which must be exact. Seats live as rows in a relational database, one row per seat, with a status and a hold expiry. Claiming is a single conditional update: set this seat to held by me with an expiry, where the seat is currently available or its hold has expired. If it updates one row, I have it; if zero rows, someone else does. That one statement is the correctness guarantee. It is atomic in the database, so there is no window between checking and taking. I would say plainly that I am not doing a read then a write in application code, because that is the race itself.

Justification for a relational database here: the contended write volume is tiny (bounded by the seat count), so I do not need a distributed store, and I do need a real transaction to tie the seat to the order. Here the numbers permit the simple, correct choice, and I would say so rather than reach for something distributed.

Partitioning by event: seats for one event live together, so a hot event is one partition and other events are unaffected. Justified by blast radius: a sold-out stadium should not slow down everything else on the platform.

Payment as a saga, ordered on purpose: hold the seat, authorise the card, confirm the seat, capture the payment. Authorise-then-capture matters because voiding an authorisation is cheap and clean, while refunding a capture is slow, visible to the customer, and sometimes costs a fee. Every step carries an idempotency key.

After confirmation, everything else goes on a queue: the email, the ticket generation, the analytics, the organiser reporting. Justified by the slack analysis: none of it needs the user waiting.

Hold expiry: each hold row carries an expiry timestamp, and the claim query treats an expired hold as available. So expiry takes effect immediately at the point it matters, and a background sweeper only tidies up; it is not on the correctness path. That distinction is worth stating. A design that depends on a sweeper running on time has a window where seats are wrongly unavailable.

Hard part one: contention on the same rows. Twenty thousand people want the front row. The conditional update means 19,999 of them get zero rows updated, which is correct but means the database is processing 20,000 write attempts against a handful of rows, all serialising on the same locks. Several things help. The waiting room is the biggest: it caps the arrival rate, so this is thousands rather than tens of thousands. Making "best available seat" the default flow, rather than seat picking, spreads attempts across the inventory instead of concentrating them. And I can reject early: if the cached view says a seat has been taken, reject before the database, accepting that this is only a signal and the database remains the authority. Cost: early rejection can occasionally reject a seat that just became available again through an expiry, so it must never be the only check.

On distributed locks, since interviewers often push here: I do not need one, and I would say why. A distributed lock is for coordinating across systems that have no shared point of serialisation. I have one, the database row, and a conditional update on it is atomic, faster, and cannot suffer the failure mode where a lock holder pauses, its lease expires, and two workers believe they hold it. Adding a lock on top would be strictly worse: more moving parts, one more thing to fail, and no additional guarantee. Choosing the simpler mechanism and explaining the rejection is worth more than demonstrating I know what Redlock is.

Hard part two: the payment boundary, in detail. Authorise while the hold is valid. If the authorisation is slow and the hold lapses mid-payment, do not silently extend it. Try to re-claim the seat, and if it has gone, void the authorisation and tell the user clearly that their seat was released and they have not been charged. That is a bad experience, so I would shorten it: extend the hold once when payment begins, since the user has demonstrated intent. Cost: a slightly longer worst-case hold, and a small amount of inventory held by people who ultimately fail to pay.

If the payment succeeds and the confirmation write fails, the reconciliation job is what saves you: it compares authorisations against confirmed orders and either completes the order — using the payment reference as the idempotency key — or voids. Cost: a background job to build and monitor, and a few customers in an ambiguous state for minutes. At volume some of those cases will happen; the choice is whether you find them or the customer does.

Fairness, which is a real requirement here and easy to forget: the queue must be first-come-first-served in an observable way, or users believe it is rigged, and for high-demand events that becomes a public problem. Cost: strict ordering in the queue is more expensive than approximate ordering, and it is worth paying for on this product specifically.

Bots: the waiting room, per-account hold limits, and payment verification do most of the work. Cost: legitimate buyers occasionally get blocked, so there must be a support path. A false positive here is a furious customer who missed the sale.

Consistency per feature, stated separately: the seat map is eventually consistent and visibly a few seconds stale. The claim is strictly serialised. The order record is strongly consistent and durable. The organiser dashboard is eventually consistent and minutes behind, which is fine.

What I would monitor: hold-to-purchase conversion, the rate of claim attempts that fail because the seat is gone, expired holds per minute, and the count of orders in an ambiguous payment state. That last number tells you whether the saga is working.