Getting Ready: Movie Ticket Booking

Every time you book a movie ticket on BookMyShow, Fandango, or AMC Theatres, you interact with a system that must solve a surprisingly hard problem: hundreds of users looking at the same screen, selecting the same seats, at the same time — and the system must guarantee that exactly one person gets each seat.

This is not a toy problem. BookMyShow processes over 30 million tickets per month across 6,000+ screens. When a blockbuster opens — say an Avengers premiere — thousands of users flood the same showtime within seconds. The system must handle seat selection, temporary holds while the user enters payment details, automatic release if the user abandons checkout, and confirmation once payment succeeds. Getting any of these wrong means double-booking (two people arrive for the same seat) or lost revenue (seats appear unavailable when they're actually free).

From an engineering perspective, the Movie Ticket Booking System is one of the best LLD problems because it naturally combines several challenges that simpler problems address in isolation:

• State management — a booking flows through multiple states (PENDING → CONFIRMED → CANCELLED), and each transition has strict rules
• Temporal logic — seats are held for a limited time (typically 5-10 minutes) and must auto-release if the hold expires
• Concurrency — two users selecting the same seat at the same moment is the normal case, not an edge case
• Multi-entity relationships — movies, theatres, screens, shows, seats, bookings, payments, and users are all interconnected
• Pricing strategy — ticket prices vary by seat type (Standard, Premium, VIP), showtime (matinee vs. evening), and day (weekday vs. weekend)

This problem appears frequently in LLD interviews at companies like Amazon, Netflix, Uber, and Flipkart — precisely because it tests whether a candidate can design beyond simple CRUD and handle real concurrency scenarios.

Over the next 9 tutorials, you'll build a complete Movie Ticket Booking System from scratch:

• Model a multi-entity domain — design the relationships between Movie, Theatre, Screen, Show, Seat, Booking, and Payment (Fundamentals S4: Relationships)
• Create 4 UML diagrams — Use Case, Class, Sequence, and State Machine diagrams that each reveal a different dimension of the system
• Apply the State Pattern — model booking status transitions (PENDING → CONFIRMED → CANCELLED) with state-specific behavior (Fundamentals S12)
• Apply the Strategy Pattern — implement pluggable pricing algorithms that compute ticket cost based on seat type, showtime, and demand (Fundamentals S12)
• Apply the Observer Pattern — notify users when booking status changes, seats become available, or shows are about to start (Fundamentals S12)
• Design a seat-locking mechanism — implement temporary holds with timeout-based auto-release to handle concurrent booking attempts
• Implement in Python and Java — complete, compilable code for every class in the diagram
• Handle concurrency explicitly — understand why naive booking fails under concurrent access and how optimistic/pessimistic locking solves it

Before starting this problem, make sure you're comfortable with:

• OOP Fundamentals — classes, objects, encapsulation, abstraction (Fundamentals S1-S2)
• Inheritance and Polymorphism — you'll need abstract classes and polymorphic method dispatch (Fundamentals S3)
• OOP Relationships — especially the difference between Composition and Association. The Theatre-Screen relationship is Composition; the Booking-User relationship is Association (Fundamentals S4)
• UML Class Diagrams — how to read and draw class boxes, relationships, multiplicities, and stereotypes (Fundamentals S5)
• UML Sequence Diagrams — lifelines, activation bars, message arrows, and alt fragments (Fundamentals S5)
• UML State Machine Diagrams — states, transitions, events, guards, and actions (Fundamentals S5)
• SOLID Principles — especially Open/Closed (for pricing strategy) and Single Responsibility (for separating booking logic from payment) (Fundamentals S6)
• State Pattern — the booking lifecycle is a textbook State Pattern application (Fundamentals S12)
• Strategy Pattern — pricing varies by seat type and showtime, making it a natural Strategy application (Fundamentals S12)
• Observer Pattern — notifications on booking confirmation, cancellation, and seat availability changes (Fundamentals S12)

If you've completed the easy and medium problems (DP1-DP18), you have all the foundations. This problem layers concurrency handling on top of patterns you've already practiced.

We will design:

• The complete domain model — Movie, Theatre, Screen, Show, Seat, Booking, Payment, and User classes
• The booking workflow — seat selection → temporary hold → payment → confirmation (or timeout → release)
• The seat-locking mechanism — how we prevent double-booking with temporal holds
• Pricing strategy — pluggable pricing based on seat type, showtime, and demand
• Booking state machine — transitions between PENDING, CONFIRMED, CANCELLED, and EXPIRED states
• Notification dispatch — notifying users of booking status changes

We will NOT design:

• Database schemas or SQL queries — this is an OOP design, not a persistence layer
• REST API endpoints — no HTTP routes or controllers
• UI/frontend — no seat map rendering or checkout pages
• Payment gateway integration — we model Payment as a class, but the actual Stripe/PayPal integration is out of scope
• Search and recommendation engine — how users find movies is a system design concern, not LLD
• Distributed systems — no microservices, message queues, or horizontal scaling

Difficulty: Hard — This problem has 10-15 classes, 4 UML diagram types, 3 design patterns, and a dedicated concurrency tutorial. It's a significant step up from medium problems because the concurrent seat-locking mechanism requires careful reasoning about race conditions and temporal state.

Interview time allocation: In a 45-minute LLD interview, spend 5 minutes on requirements, 15 minutes on the class diagram, 10 minutes on the booking sequence, 10 minutes on concurrency/seat locking, and 5 minutes discussing trade-offs and extensions.