SYSTEM DESIGN · QUESTION 112
How would you design a ticket-booking system for high-demand events?
On this page
I would clarify inventory, sale windows, holds, payment timeouts, and fairness. Use a durable seat inventory with atomic reservation or compare-and-set, create expiring holds, and confirm only after payment succeeds. A queue can smooth traffic, but correctness belongs in the inventory transaction. Make requests idempotent and define hold expiry, cancellation, and reconciliation so seats are not oversold or stuck.
LET'S MAKE IT SIMPLE
First, the idea in plain English
Many people may try to buy the same limited seat at once. A search result that says a seat is available can become stale before checkout. The system must reserve it atomically for a short time and either confirm the purchase or release it when the hold expires.
A USEFUL COMPARISON
Picture it this way
A shop clerk puts one item on hold for a customer for a limited time. Another clerk must see that hold before promising the same item. If the customer does not complete checkout, the item returns to stock.
FOLLOW THE JOURNEY
Use expiring holds and atomic inventory transitions
Trace seat availability, hold creation, payment, confirmation, and release.
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Inventory must recover predictably.
A purchase request enters a queue, atomically holds one available seat until expiry, confirms after payment, or releases inventory on timeout or cancellation.
How to read this visual
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Inventory must recover predictably.
UNDER THE HOOD
How it works, step by step
Control sale traffic
Authenticate buyers and use queues or admission control.
Why it matters: Traffic shaping protects the inventory system.
Create a hold
Atomically change a seat from available to held with an expiry.
Why it matters: Only one request should win a specific seat.
Complete payment
Use an idempotent payment workflow before confirmation.
Why it matters: A pending payment must not permanently consume inventory.
Confirm or release
Finalize the booking or release expired and failed holds.
Why it matters: Inventory must recover predictably.
OUTSIDE THE TEXTBOOK
A practical example
Two buyers select the same seat at nearly the same time. A conditional database update allows only one hold to transition from available to held. That buyer receives a short checkout window; payment success confirms the booking, while timeout releases the seat for another buyer.
GO A LITTLE DEEPER
Technical details that matter
- Use conditional writes or serializable transactions for inventory contention.
- Payment and reservation are separate systems, so workflows need idempotency and compensation.
- Queues and waiting rooms improve load management but do not replace inventory correctness.
MAKE A GOOD CHOICE
When is this useful?
- Concert, travel, appointment, or limited-stock reservations.
- Any scarce resource with concurrent purchase attempts.
- Systems requiring temporary holds before an external payment completes.
For general merchandise with many interchangeable units, quantity counters may be simpler than assigning individual seat records.
WATCH OUT FOR
Common misunderstandings
- Checking availability and updating later without an atomic guard.
- Holding inventory forever after a payment timeout.
- Assuming a waiting room prevents duplicate reservations.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Hot events create contention and uneven queue times.
- Payment outcomes can be uncertain after network failures.
- Fairness policies can conflict with throughput and fraud controls.
WHAT TO REMEMBER
Key takeaways
- 1Availability checks must become atomic holds.
- 2Use expiry and idempotent payment workflows.
- 3Traffic shaping helps scale but correctness belongs at the inventory boundary.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
How do you avoid overselling?
Use a conditional atomic transition or transaction on inventory and confirm exactly one winner for each seat or unit.
What if payment times out?
Treat the result as uncertain, reconcile with the payment provider, and keep or release the hold according to a bounded policy.
SAY IT OUT LOUD
How to explain this in an interview
“I would model each seat through available, held, booked, and released states. A conditional transaction creates an expiring hold so concurrent buyers cannot claim the same inventory. Payment uses an idempotent workflow; confirmed success books the seat, while timeout or failure eventually releases it. A queue protects capacity but does not replace atomic inventory control.”
Connect this question to the roadmap topic it supports.