sydepsystem design atlas

Event Ticket Booking

Reserve seats atomically to prevent double-booking under high concurrency.

IntermediateCommerce
ClientClientAPI GatewayNetworkingBooking ServiceComputeSeat Lock StoreStorageBookings DBStoragePayment ServiceCompute

Seat availability is held in a fast, strongly consistent store with short-lived locks during checkout, so many concurrent buyers competing for the same seats can never both succeed.

When to use it

  • Inventory is a fixed, contended resource (seats, slots) with bursty demand at on-sale time
  • Double-booking the same seat is unacceptable, even under a traffic spike

Trade-offs

  • Seat locks held too long during slow checkouts reduce effective availability for others
  • On-sale traffic spikes require aggressive rate limiting or the reservation store becomes the bottleneck

Components used

Web AppAPI GatewayManaged App ServiceCacheRelational Database

How it works

  • Seat inventory is held in a store supporting atomic conditional updates, so two concurrent buyers cannot both claim one seat.
  • Selecting a seat creates a short-lived hold with a TTL, giving the buyer time to pay without permanently removing the seat if they abandon.
  • A queue or waiting room absorbs the initial traffic surge so the inventory store sees an admissible request rate rather than the full flood.

Used in the wild

  • Concert and sports ticketing with high-demand on-sales.
  • Limited-inventory product drops.
  • Exam or appointment slot booking.

Good to know

  • This is the canonical high-contention problem: a huge crowd racing for the same few thousand rows at the same instant. Ordinary optimistic locking degrades badly because nearly every attempt conflicts.
  • The virtual waiting room exists as much for fairness and perception as for load. A queue position feels acceptable to users; a timeout or error does not.