Design BookMyShow

Problem Design BookMyShow: browse movies/shows and theatres, view seat maps, select seats, and book — preventing double-booking under high concurrency.

Functional requirements

• Search by city/movie/date → shows; seat-map view with live availability; seat selection with a temporary hold; payment and confirmed ticket; cancellations.

Non-functional requirements

• Blockbuster-opening spikes: thousands of users contending for the same show's seats simultaneously; seat booking must be strictly consistent; browsing can be eventually consistent and heavily cached.

Key components

• Search/catalog service (movies, theatres, shows — cache/CDN heavy), seat-inventory service (source of truth per show), booking service (hold → pay → confirm state machine with TTL holds), payment integration, notification/ticket service.

Deep dives / trade-offs

• Double-booking prevention: per-seat rows with unique constraint (show_id, seat_id) + transactional hold, or Redis SETNX with TTL for the hold layer backed by DB confirmation; optimistic vs pessimistic locking under hot contention.
• Data scaling: partition by city/theatre/show — show_id as the natural shard key; consistent hashing to spread hot shows across nodes and to keep resharding cheap; why a busy show must not pin one shard (hot-partition mitigation).
• DB choices per service: relational for booking/inventory (transactions), document/search index for catalog, Redis for holds and seat-map caching; queue for booking confirmations/notifications.
• Virtual waiting room / queueing for extreme launches — degrade fairly instead of collapsing.