Ticketmaster / Hotel Booking

Don't oversell. Hold-then-confirm.

SavedSaved on this device

The problem

Don't oversell. Hold-then-confirm.

Build a system that sells finite inventory under high contention without overselling. The canonical examples are Ticketmaster (concert tickets) and Booking.com / Airbnb / Expedia (hotel rooms) — but the pattern generalizes to airline seats, restaurant tables, exam slots, ride dispatching, any limited-quantity-for-sale resource. The load-bearing technical reality is the same in all of them:

Inventory is finite — there are N tickets to this concert, M rooms at this hotel on this date.
Demand can dwarf supply — Taylor Swift Eras Tour onsale: 14M users showed up for a system sized for 1.5M; 3.5M Verified-Fan pre-registrations alone exceeded the previous all-time peak by 4×.
You can't oversell — selling the same seat twice destroys customer trust and triggers chargebacks / regulatory complaints / class actions.
You can't lose money on retries — when the user mashes "Pay" three times in 200ms because the network blipped, they must end up with one charge and one booking — not three of each, not zero of either.

The pattern that emerged across Ticketmaster, SeatGeek, StubHub, Booking.com, Airbnb, Expedia, and the broader ticketing/lodging industry is hold-then-confirm:

User picks a seat / room → system places a soft hold with a TTL (5–15 min) — Redis SET NX PX is the dominant primitive.
User completes payment within the hold window → system confirms via a strongly-consistent durable write that ties the booking commit, the idempotency claim, and the outbox publish into one transaction.
Hold expires (TTL or explicit cancel) → seat returns to the pool automatically — no janitor job; Redis PX expiry does the work.

Reading: Ticketmaster SmartQueue (blog.ticketmaster.com) · SeatGeek virtual waiting room (InfoQ + AWS Architecture Blog) · Stripe — Designing robust APIs with idempotency · Booking.com — Using Riak as Events Storage · Airbnb — Partitioning the main DB · Brandur — Implementing Stripe-like idempotency keys in Postgres · Cockroach Labs — Technical takeaways from the Ticketmaster/Eras meltdown

inventory locking
hold-then-confirm
virtual waiting room
idempotency keys
transactional outbox
hot-event sharding
saga / compensation

01Clarifications

What would you ask before drawing a single box?

Ambiguity you would resolve with the interviewer: scope, scale, who uses it, what counts as done.

About Ticketmaster / Hotel Booking

Don't oversell. Hold-then-confirm.

Difficulty: intermediate
Time: about 55 minutes
Stages: 10
Topic: Transactions, Concurrency & Money

How this problem is worked

Ten stages, from the questions you would ask an interviewer to the trade-offs you would defend. Each asks one question, and the simulator runs the architecture you draw against the requirements you wrote.

01ClarificationsWhat would you ask before drawing a single box?
02Functional reqsWhat must this system actually do?
03Non-functionalWhat must it promise about speed, uptime and correctness?
04Capacity estimationHow much load and data does this have to hold?
05API designWhat does the outside world call, and what comes back?
06Data modelWhat gets stored, and what is it looked up by?
07Use-case breakdownHow does each requirement actually get served?
08High-level designWhich components handle a request, and in what order?
09Deep divesWhich part breaks first, and what do you do about it?
10Trade-offsWhat did this design cost, and what breaks at 10×?

Primary sources for this problem

Ticketmaster SmartQueue (blog.ticketmaster.com)
SeatGeek virtual waiting room (InfoQ + AWS Architecture Blog)
Stripe — Designing robust APIs with idempotency
Booking.com — Using Riak as Events Storage
Airbnb — Partitioning the main DB
Brandur — Implementing Stripe-like idempotency keys in Postgres
Cockroach Labs — Technical takeaways from the Ticketmaster/Eras meltdown

More in Transactions, Concurrency & Money

Correctness when two writers collide and money is involved: serializability, two-phase commit versus sagas, hold-then-confirm, single-writer matching, and the databases that give you external consistency.

Browse the full problem catalog, or see what the simulator does and does not model.