1. Requirements (The Scope)
- Functional:
- Browse movies by city.
- Choose a cinema and a showtime.
- Select seats and pay.
- Handle seat locking (Temp-hold for 10 mins).
- Non-Functional:
- High concurrency for popular movies.
- No double-booking.
2. Entity Identification
Cinema: Contains multiple screens.Show: Mapping of Movie, Screen, and Time.Seat: Has a type (Gold, Silver) and Status (Available, Locked, Booked).Booking: Represents a successful transaction.SearchService: Optimized for city/movie filtering.
3. Handling Seat Concurrency (The "Senior" Part)
When two users click the same seat at the exact same millisecond, how do you handle it?
- Optimistic Locking: Use a version field in the DB.
- Pessimistic Locking: Lock the
Seatrow in the database while the user is in the payment flow.
4. The State Pattern
Use the State Design Pattern to manage seat lifecycle:
AvailableState$\rightarrow$LockedState(User starts checkout).LockedState$\rightarrow$BookedState(Payment success).LockedState$\rightarrow$AvailableState(Timeout or payment fail).
Final Takeaway
BookMyShow is a State Management problem. Using the State pattern shows you can handle complex logic transitions without messy if-else blocks.