Design BookMyShow / Ticketmaster (Concurrent Seat Booking)
High-contention seat reservations: locking, idempotent payment, queue-based fairness, anti-bot, and inventory consistency at flash-sale scale.
Intro
Seat-booking systems combine inventory management with payments — the classic 'concurrency at the boundary' problem. The hard cases are flash sales (Taylor Swift, IPL finals) where 100 k+ users try to book the same seats simultaneously. The decisive design choice is how to enforce 'one buyer per seat' — pessimistic locking, optimistic locking, or queue-based fairness.
Functional
- Browse shows + venues + available seats.
- Reserve seats temporarily (5-min hold) before payment.
- Atomic seat purchase + payment.
- Cancellations + refunds.
Non-functional
- Reservation must be unique — no double-booking.
- p95 reserve < 1 s; payment p95 < 5 s end-to-end.
- Flash sale: 100 k concurrent users on a single show.
- Inventory accuracy 100% — every seat exactly once.
Components
Catalog service
Shows + venues + seat maps.
Inventory service
Holds seat state with strong consistency.
Reservation service
Manages temporary holds with TTL.
Payment service
Idempotent payment via PSP (see payments HLD).
Queue service
Virtual waiting room for flash sales.
Anti-bot
Rate limit + CAPTCHA + behavior signals.
Trade-offs
Pessimistic vs optimistic locking
Pros
- Pessimistic: zero rollback.
- Optimistic: better throughput in low-contention.
Cons
- Pessimistic: deadlock risk.
- Optimistic: rollback storms in flash sale.
Synchronous payment vs reserve-then-pay
Pros
- Sync: immediate confirmation.
- Reserve-then-pay: smoothes flash sale.
Cons
- Sync: PSP latency on hot path.
- Reserve-then-pay: more state to manage.
Scale concerns
- Flash sale — 100 k concurrent.
- Bots — must throttle without breaking real users.
- Inventory drift — TTL expiry must release seats.
- Payment failures — release seats promptly.