Loading LLD design...
Design an object-oriented movie ticket booking system (like BookMyShow) with a Cinema → Screen → Seat hierarchy, movie catalogue, shows (screenings) with per-seat-type pricing, a two-step booking flow (hold → confirm), and seat hold expiry.
Each screen has rows of typed seats (Regular, Premium, VIP, Recliner). When a show is scheduled, a seat map is created with prices derived from the seat type. Users select seats which are temporarily held for 10 minutes (AVAILABLE → HELD). Upon payment, seats transition to BOOKED. If the hold expires, a background sweep releases seats back to AVAILABLE. Bookings can be cancelled with automatic seat release and refund.
Manage movie catalogue
Add movies with title, description, duration, language, genre, rating
Manage cinemas and screens
Add cinemas with screens; each screen has rows of typed seats (Regular, Premium, VIP, Recliner)
Schedule shows
Create a screening of a movie on a specific screen at a specific time with per-type pricing
Search movies and shows
Search movies by title/genre/language; browse shows by movie/city/date
View available seats
Display seat map for a show with availability and prices by seat type
Hold seats (temporary)
Temporarily hold selected seats for 10 minutes while user completes payment
Confirm booking
Process payment and transition booking from PENDING to CONFIRMED
Cancel booking
Cancel a confirmed booking, release seats, and process refund
Expire stale holds
Background sweep to release seats whose hold has timed out
Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.
Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.
Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.
What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.
What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.