Design Ticket Booking System (BookMyShow)

1. Requirements & Assumptions

Functional Requirements

• The system must list movies in different cities.
• Each city has multiple theaters, and each theater contains multiple screens.
• Each screen runs multiple shows (a movie, start time, and end time).
• Users can view seat layouts and select seats (e.g., A1, A2) for a show.
• Users can book selected seats. Once seats are booked, they cannot be booked by other users.
• Supports a temporary Seat Locking mechanism (e.g., locks seats for 5 minutes during checkout).

Non-Functional Requirements

• High Concurrency & Consistency: The system must prevent double-booking of seats under high traffic (e.g., blockbusters release).
• Low Latency: Seat layout checks and availability queries must return instantly.

Assumptions

• Payments are processed through a third-party gateway interface.
• Only one language interface is required for the demo.

2. Entities, Responsibilities & Relationships

• CinemaSystem (Facade): Simplifies operations like searching movies, showing seats, and booking.
• Theater & Screen: Model the physical spaces.
• Show: Binds a Movie to a specific Screen and start time.
• ShowSeat: Represents a specific seat for a specific show, tracking its booking status (Available, Locked, Booked).
• Booking: Tracks ticket details, user information, and transaction status.

3. Diagrams

UML Class Diagram

Sequence Diagram: Booking Seats

4. Design Decisions

• State Transitions for Seats: We use a SeatStatus enum (AVAILABLE, LOCKED, BOOKED) to manage seat availability. Locking seats temporarily prevents double-booking while users enter payment details.
• Pessimistic Locking on Seat Objects: To ensure thread safety under high concurrency, we lock individual ShowSeat objects during the select-and-lock phase. This allows users to book different seats concurrently without blocking one another.

5. Step-by-Step Implementation

1. Define Movie, Theater, and Screen entities.
2. Implement ShowSeat with thread-safe lock/book operations.
3. Create Show to tie a movie to a screen and manage its seat layout.
4. Implement Booking to track transaction records.
5. Create CinemaSystem as a facade to coordinate bookings.

6. Complete Code

7. Test Cases & Verification

• Test Case 1: Simple Success: Request Seat 1 and Seat 2 for a show. Verify that both are locked, payment succeeds, seats are booked, and a ticket is issued.
• Test Case 2: Concurrent Seat Contention: Thread A attempts to book Seat 3. Thread B concurrently attempts to book Seat 3 and Seat 4. Verify that one thread succeeds, while the other receives a "Booking failed" notification and any partial seat locks are rolled back.

8. Scalability & SOLID Improvements

• SOLID - Interface Segregation: The booking system segregates pricing and payment validation interfaces, allowing us to swap payment gateway implementations easily.
• Scalability - Distributed Locks: For large-scale distributed deployments, Java synchronized blocks are insufficient. You should use distributed lock managers like Redisson (Redis) to lock seat keys (e.g. lock:show:101:seat:A1) across multiple application nodes.

9. Production Considerations

• Database Indexing: Search queries for active shows must be optimized. Create composite indexes on (movie_id, show_date, theater_id) to speed up read queries.
• Automated Lock Eviction: Use a TTL cache or Redis Keyspace Notifications to automatically release seat locks if the user does not complete checkout within 5 minutes, returning the seats to the pool.

10. Next Lesson Preview

In the final case study, we will design a Chess Game. We will study board cell coordinates, piece polymorphism (Pawn, Rook, Knight, etc.), and turn-based game loop validation!