Design Booking System (BookMyShow)

Oracle's "Design Booking System (BookMyShow)" interview question focuses on architecting a scalable movie ticket booking platform like BookMyShow, emphasizing concurrency control, transactions, and data consistency.

Problem Statement

Design a high-performance ticketing system supporting movie/show selection, seat booking across theaters/screens, payments, and cancellations. Key goals include preventing double-booking under high concurrency (e.g., popular shows), ensuring ACID-compliant transactions for payments, and handling seat locks with timeouts (typically 10 minutes). The system must scale for millions of users, support aggregators (e.g., partner apps sharing seat inventory), and provide real-time availability updates.[1][3]

Functional Requirements

• Users browse movies, theaters, shows, and seat layouts (regular, premium, accessible seats).
• Select multiple seats; system temporarily locks them (FIFO order for fairness).
• Complete payment to confirm booking; generate unique ticket ID.
• Support cancellations with refunds (before check-in).
• Aggregators get reserved seat quotas or dynamic availability syncs.
• APIs for seat availability, booking, and timeout checks.[3][1]

Non-Functional Requirements

• Throughput: Handle 10,000+ concurrent bookings per popular show without overbooking.
• Consistency: ACID transactions; optimistic locking or DB-level locks for seats.
• Availability: 99.99% uptime; use caching (Redis) for reads, master-slave RDBMS for writes.
• Latency: <200ms for searches, <1s for bookings.
• Scalability: Sharding by theater/show; handle global traffic with CDNs.[1]

Key APIs with Inputs/Outputs

| API | Request Inputs | Response Outputs | Constraints | |-----|----------------|------------------|-------------| | SearchMovies | city, date | List of movies/shows | Paginated; cached.[1] | | GetShowSeats | showId | Seat map (available/locked) | Real-time; row/col layout.[1] | | BlockSeats | userId, seatIds[] | Block confirmation, 10-min timeout | Max 10 seats; temporary lock.[1] | | BookSeats | userId, seatIds[], paymentDetails | Ticket ID, payment status | Idempotent; atomic with payment.[1] | | GetTimeout | seatIds[] | Remaining time (seconds) | For locked seats only.[1] | | CancelBooking | bookingId | Refund status | Before showtime; partial OK.[3] |

Constraints

• Concurrency: No double bookings—use versioning, distributed locks (ZooKeeper/Redis), or queueing (Kafka).
• Scale: 1M+ daily bookings; 100 theaters/city, 500 seats/screen.
• Data: Seats update frequently; aggregators reserve 10-20% inventory.
• Edge cases: Network failures (retry with idempotency), payment timeouts (release seats), high-demand flashes.[7][3][1]