A movie ticket booking system solves a deceptively hard problem: managing shared, finite resources (seats) under concurrent access. Two users staring at the same seat map at the same time should not both successfully book seat C5. This is not just a data modeling exercise; it is a concurrency and reservation design problem. The user workflow is straightforward. A customer browses movies, picks a show (a specific movie at a specific screen and time), views a seat map, selects seats, and completes payment. But beneath that simple flow lies a critical timing challenge. Between the moment a user selects seats and the moment they complete payment, those seats must be temporarily reserved: visible to other users as unavailable, but not yet permanently booked. If the user abandons the booking or their payment fails, the seats must automatically return to the available pool.

The core entities map directly from the domain. A Cinema contains multiple Screens. Each Screen has a fixed seat layout (rows and columns). A Movie is a film title with metadata. A Show connects a Movie to a Screen at a specific date and time: this is the bookable unit. Each Show has its own seat availability because the same Screen hosts different Shows throughout the day. A Seat belongs to a Show (not to a Screen) because availability is per-show. Seat C5 might be booked for the 7 PM show but available for the 9 PM show. Each Seat tracks its state: Available, Held, Booked, or Cancelled. A Booking links a User to a set of Seats for a specific Show, along with payment status. The non-functional requirements drive key design decisions. Holds must expire after a configurable timeout (typically 10 minutes). The system must prevent double-booking under concurrent access. Cancellations within a refund window should return seats to the available pool. And the seat map display must reflect real-time availability, including currently held seats.