Requirements for the Booking System

Let's define what our Movie Ticket Booking System needs to do. Each requirement is numbered for traceability — we'll reference these IDs when justifying class diagram decisions and code implementations later.

1. R1: Movie Management — The system shall store movies with attributes including title, description, duration, language, genre, and release date. A movie can have multiple shows across different theatres.

2. R2: Theatre and Screen Management — The system shall support multiple theatres, each containing one or more screens. Each screen has a fixed seating layout with a known capacity.

3. R3: Show Scheduling — A show associates a movie with a specific screen at a specific date and time. The same movie can run on multiple screens and multiple showtimes. No two shows may overlap on the same screen.

4. R4: Seat Types — Each screen has seats categorized by type: Standard, Premium, and VIP. Seat types determine base pricing. The seating layout is fixed per screen (row and column positions).

5. R5: Seat Availability — The system shall allow users to view available seats for a given show. A seat is available if no active booking (PENDING or CONFIRMED) exists for it in that show.

6. R6: Seat Selection and Temporary Hold — When a user selects seats, the system shall place a temporary hold on those seats for a configurable duration (default: 8 minutes). During the hold, no other user can select those seats. If the user does not complete payment within the hold period, the seats are automatically released.

7. R7: Booking Creation — A booking aggregates one or more seats for a single show, associated with a single user. The booking is created in PENDING status when seats are held.

8. R8: Payment Processing — The system shall accept payment for a pending booking. Upon successful payment, the booking transitions to CONFIRMED. Upon payment failure, the booking transitions to CANCELLED and seats are released.

9. R9: Booking Cancellation — A user may cancel a CONFIRMED booking before the show starts. Cancellation releases the seats and may trigger a refund (refund policy is out of scope for this design).

10. R10: Booking Status Lifecycle — A booking shall follow a strict state machine: PENDING → CONFIRMED (on payment success), PENDING → EXPIRED (on hold timeout), PENDING → CANCELLED (on payment failure or explicit cancel), CONFIRMED → CANCELLED (on user cancellation). No other transitions are allowed.

11. R11: Pricing Strategy — Ticket price shall be computed dynamically based on seat type, showtime (matinee discount, evening premium), and optionally day of week (weekend surcharge). The pricing algorithm must be pluggable without modifying booking logic.

12. R12: Notifications — The system shall notify users when a booking is confirmed, cancelled, or approaching showtime. The notification mechanism (email, SMS, push) is abstracted behind an interface.

13. R13: Search — Users shall be able to search movies by title, genre, or language, and search shows by movie, theatre, city, or date.

Beyond functionality, our design must satisfy these quality attributes:

1. Concurrency Safety — Multiple users may attempt to book the same seats simultaneously. The system must guarantee that no seat is double-booked. This is the primary engineering challenge of this problem — it drives the seat-locking mechanism (R6) and is the subject of a dedicated tutorial.

2. Extensibility (Open/Closed Principle) — Adding a new seat type (e.g., Recliner), a new pricing model (e.g., surge pricing), or a new notification channel (e.g., WhatsApp) must not require modifying existing classes. This drives our use of Strategy, Observer, and interface-based design.

3. Temporal Correctness — Seat holds must expire reliably. A hold that never expires blocks seats permanently. A hold that expires prematurely double-books seats. The timeout mechanism must be deterministic.

4. Testability — Each component must be testable in isolation. Pricing strategies testable without bookings. Booking state transitions testable without payments. Seat availability testable without UI.

5. Single Responsibility — Booking logic, payment processing, pricing calculation, and notification dispatch must reside in separate classes. No God class that handles everything.

In Scope:

• Complete domain model: Movie, Theatre, Screen, Show, Seat, ShowSeat, Booking, Payment, User
• Booking workflow: select seats → hold → pay → confirm (or timeout → expire)
• Seat availability lookup per show
• Pricing computation with pluggable strategy
• Booking state machine with all valid transitions
• Concurrent seat-locking mechanism
• Notification dispatch interface
• Search functionality (basic, not full-text search)

Out of Scope:

• Database persistence — we model in-memory state; how to store to a database is a system design concern
• REST API design — no HTTP endpoints, request/response formats, or authentication layers
• Payment gateway integration — we model Payment as a class with status, but actual Stripe/PayPal calls are abstracted
• Refund policies — cancellation releases seats but refund calculation rules are domain-specific and out of scope
• Seat map rendering — the visual seat selector is a frontend concern
• Distributed locking — we design the locking semantics for a single-process system; distributed locks (Redis-based, ZooKeeper) are system architecture concerns
• Movie recommendations and ratings — these are product features, not OOP design exercises

Every requirement must map to at least one design element. Here's the traceability preview — we'll verify this mapping as we build the class diagram:

Requirement	Design Element	Pattern/Concept
R1: Movie management	Movie class	Domain entity
R2: Theatre structure	Theatre, Screen classes	Composition (Theatre owns Screens)
R3: Show scheduling	Show class	Association (Movie + Screen + DateTime)
R4: Seat types	SeatType enum, Seat class	Enum-based type safety
R5: Seat availability	ShowSeat class	Per-show seat status tracking
R6: Temporary hold	ShowSeat.status, timeout logic	State management, temporal hold
R7: Booking creation	Booking class	Aggregation of ShowSeats
R8: Payment	Payment class	Separated from Booking (SRP)
R9: Cancellation	State transition in Booking	State Pattern
R10: Status lifecycle	BookingStatus enum + state machine	State Pattern (Fundamentals S12)
R11: Dynamic pricing	PricingStrategy interface	Strategy Pattern (Fundamentals S12)
R12: Notifications	NotificationService interface	Observer Pattern (Fundamentals S12)
R13: Search	MovieService.search()	Filtering and lookup

Key observation: The ShowSeat class — which tracks the status of a specific seat for a specific show — is the most important design decision. A physical Seat (row 5, column 3) exists permanently on a screen. But its availability changes per show. ShowSeat bridges this: it associates a Seat with a Show and tracks whether that seat is AVAILABLE, HELD, or BOOKED for that particular showing.

In a real interview, spend the first 3-5 minutes clarifying requirements before designing. Here are the questions that distinguish a strong candidate:

• "Should the system support multiple theatres in multiple cities?" — Yes, but city-level search is the only cross-city concern. Each theatre's seat map is independent.
• "How long should the seat hold last?" — Configurable, default 8 minutes. This is critical — too short and users can't complete payment; too long and popular shows appear sold out.
• "Can a user hold seats for multiple shows simultaneously?" — Yes. Each booking is independent.
• "What happens if payment times out but the user's bank has already charged?" — Out of scope for LLD. In a real system, this involves reconciliation and idempotency — but that's system design, not object modeling.
• "Is the seat layout the same for every screen?" — No. Each screen has its own layout (rows, columns, seat types). The Seat objects are fixed per screen.

Notice how these questions naturally uncover requirements R6 (hold duration), R2 (multi-theatre), and R4 (per-screen layouts). The interviewer is testing whether you think about edge cases before coding.