BookMyShow System Design: Seat Booking Concurrency

The system splits hard into a read plane and a write plane, because they have opposite requirements. The read plane, movie/event catalog, city/cinema/show listings, and the seat map, is overwhelmingly the traffic (roughly 450 reads per write) and tolerates being slightly stale. It's served from a CDN for static assets and a cache (Redis/ElastiCache) for seat maps and show metadata, fronted by stateless API servers behind a load balancer. This plane scales horizontally with no coordination. The write plane is the entire interview. It's narrow on purpose. Before a user can even attempt a booking on a hot show, they pass through a virtual waiting room (BookMyShow has used Queue-it and Cloudflare Waiting Room): the edge issues a signed token granting a queue position, and the room admits users to the live booking service at a controlled rate, a few thousand per second, regardless of how many millions are waiting. This is load-shedding: it converts an uncontrollable thundering herd into a bounded, predictable stream the backend can actually handle. Without it, the 2015 IPL-final collapse (500k+ simultaneous users) repeats. Once admitted, seat selection acquires a temporary hold in Redis. The hold is a key like seat:{showId}:{seatId} set with an atomic compare-and-set (a Lua script: "set this key to my userId only if it doesn't exist") and a TTL of ~10 minutes. Redis is the source of truth for "who currently holds this seat" precisely because that operation is atomic and sub-millisecond. If the SET succeeds, the user owns the seat; if it fails, someone else got it and the UI immediately reflects that. Because it's a single atomic op, two users clicking the same seat in the same millisecond can never both win. Holding a seat is not booking it. Payment sits in the middle, and it's slow and failure-prone, so the booking is modeled as a saga (an orchestrated state machine): create order → reserve inventory (the Redis hold) → initiate payment → on payment success, persist the booking durably to Postgres/Aurora and mark the seat permanently sold; on payment failure, timeout, or abandonment, run the compensating action, release the Redis hold so the seat returns to the pool. The hold's TTL is the safety net: even if a server crashes mid-saga, the lock auto-expires and inventory is never permanently lost. Payment confirmation arrives via webhook, which is deduplicated with an idempotency key so a retried or duplicated webhook can't create a second booking or release something it shouldn't. The confirmed booking is the only thing written to the durable relational store, where a unique constraint on (show_id, seat_id) is the final, absolute backstop against double-booking. In a real interview, sketch this on the whiteboard before diving into any single box.

In a real interview, sketch this on the whiteboard before diving into any single box.