Design a Movie-Ticket Booking System's Classes and Prevent Double Booking

Design the classes for a movie-ticket booking system. Users pick a city, browse the movies showing there, choose a show (a movie at a specific theater, screen and start time), select specific seats on that show's seat map, and pay to confirm the booking. The interviewer focuses on three things: a clean class design, the design principles that justify it, and one hard guarantee. A seat for a given show must never be sold to two people, even when many users try to book the same seats at the same moment. ### Constraints and Clarifications - Assume a booking service backed by a relational database; payment goes through an external gateway that your code calls through an interface. - Seats are chosen individually from a seat map, and one booking can include several seats for the same show. - While a user is paying, the selected seats should be held so nobody else can take them. How long a hold lasts is something to agree with the interviewer. - Search, recommendations and theater onboarding are out of scope unless time remains. ### Clarifying Questions - How long should selected seats be held while the user pays, and what happens when the hold expires? - If a user selects four seats and one of them is taken in the meantime, should the whole booking fail or should the other three go ahead? - Do prices vary by seat category, show time or day of the week? - Are cancellations and refunds in scope, and is there a cut-off before the show starts? - Is there a single service instance, or many instances behind a load balancer? ### Part 1 — Domain model Identify the classes, enums and relationships: movies, theaters, screens, physical seats, shows, the per-show state of each seat, bookings and payments. Show the key fields and methods. ```hint Seat versus seat-for-a-show A physical seat exists once, but its availability is different for every show. Decide which object carries that per-show state. ``` #### What This Part Should Cover - Entities with clear responsibilities and relationships - Separation of static data (the theater layout) from per-show state - Explicit states and allowed transitions for per-show seats and for bookings ### Part 2 — Booking flow and preventing double booking Walk through the flow from seat selection to a confirmed booking, including holds, payment and expiry. Explain exactly how two concurrent requests for the same seat are resolved so that only one succeeds, and how the design behaves with several service instances. ```hint Where the race is decided Identify the single operation that must succeed for one request and fail for the other, and which component can make that decision atomically for every service instance. ``` #### What This Part Should Cover - An all-or-nothing hold on several seats, with a clear atomicity mechanism - Hold expiry and payment outcomes, including a payment that succeeds after its hold expired - Correct behavior with multiple service instances and retried requests - Deadlock and contention considerations ### Part 3 — Design principles and extensibility Show how the design accommodates new pricing rules, new payment methods and new notification channels, and name the principles and patterns that make those changes cheap. ```hint Change one thing Pick one likely change, such as weekend pricing, and trace exactly which classes it touches in your design. ``` #### What This Part Should Cover - Principles applied with concrete examples from the model - Patterns used where they earn their place (strategy, state, observer), not as decoration - Testability of the booking logic ### What a Strong Answer Covers - A model that keeps per-show seat state separate from the physical layout - A clearly explained, airtight guarantee against double booking under concurrency - Correct handling of holds, expiry and payment failures - Principles justified by realistic change scenarios - Clear trade-offs between locking approaches ### Follow-up Questions - How would you handle a blockbuster opening where thousands of users hit the same show in the first minute? - How would the design change if seat holds were managed in a cache in front of the database? - How would you support a waitlist that offers released seats to the next user in line? - How do you guarantee that a user is never charged without receiving a booking?