Search
⌘K
Common Problems
Movie Ticket Booking
Try This Problem Yourself
Practice with guided hints and real-time feedback
Understanding the Problem
🎬 What is a Movie Ticket Booking System?
A movie ticket booking system (like Fandango) lets users search for movies, browse theaters and showtimes, select specific seats from a seat map, and reserve tickets. The system manages seat availability across multiple theaters, each with multiple screens, and prevents two people from booking the same seat.
Requirements
Your interview starts with this prompt:
"Design a movie ticket booking system similar to BookMyShow that allows users to browse movies, select theaters and showtimes, book tickets, and manage reservations."
That's broad. Before writing a single requirement, you need to narrow this down with targeted questions.
Clarifying Questions
Focus your questions on core operations, scope boundaries, and constraints.
You: "When you say 'browse movies,' is that full-text search, fuzzy matching, or just simple title lookup?"Interviewer: "Simple text matching on the movie title. Nothing fancy."
That means we can iterate through our movie list, check if each title contains the search term, and return matches. No need for Elasticsearch, inverted indexes, or ranking algorithms. With a few hundred movies in memory, a linear scan takes microseconds.
You: "How does seat selection work? Does the user pick specific seats from a map, or does the system auto-assign? And can they book more than one seat at a time?"Interviewer: "Users pick specific seats from a seat map. And yes, they can book multiple seats in one transaction."
So we're building a seat picker, not just a ticket counter. That means we need per-seat availability tracking. The actual UI for rendering the seat map is out of scope, but our system needs to expose which seats are available so a frontend could display them.
You: "Are we designing for a single theater or multiple? And do theaters have multiple screens?"Interviewer: "Multiple theaters, each with multiple screens. A user can search for a movie and see where it's playing, or go to a specific theater and see what's on."
Multi-theater with multiple screens. Two entry points into the system: search by movie title globally, or browse a specific theater's offerings. Both paths funnel into picking a showtime, then picking seats. We need to support both directions efficiently.
You: "Do different screens have different seat configurations? Or can we standardize?"Interviewer: "Standardize it. Every screen has the same layout: rows A through Z, seats 0 through 20."
Big simplification. One constant seat layout for every screen in the system means we don't need to model per-screen configurations.
You: "What does 'manage reservations' include? Cancel, reschedule, modify?"Interviewer: "Cancel only. If someone wants a different showtime, they cancel and rebook."
No rescheduling logic. That keeps the reservation model simple.
You: "A couple of scoping questions: are there different seat types with different prices? And is payment processing in scope?"Interviewer: "No to both. All seats are identical, and payment is out of scope. Assume it always succeeds."
Two fewer features to model. No pricing tiers, no payment state machine.
You: "What about concurrency? If two people try to book the same seat at the same time?"Interviewer: "Handle it. Exactly one should succeed."
Concurrency is a core requirement.
Final Requirements
Final Requirements
Requirements:
1. Users can search for movies by title
2. Users can browse movies playing at a given theater
3. Theaters have multiple screens; all screens share the same seat layout (rows A-Z, seats 0-20)
4. Users can view available seats for a showtime and select specific ones
5. Users can book multiple seats in a single reservation; booking returns a confirmation ID
6. Concurrent booking of the same seat: exactly one succeeds
7. Users can cancel a reservation by confirmation ID, releasing the seats
Out of Scope:
- Payment processing (assume payment always succeeds)
- Variable seat layouts or seat types (all seats identical)
- Rescheduling (cancel and rebook instead)
- UI / renderingCore Entities and Relationships
Scanning the requirements gives us a pool of candidates: Theater, Movie, Screen, Seat, Showtime, Reservation, and something to orchestrate it all. Not every candidate will become its own class, but they're all worth listing out. Each one shows up somewhere in the design, whether as a class, a value object, a field, or a constant.
Final Entities
Class Design
BookingSystem
Theater
Showtime
Movie
Reservation
Final Class Design
Implementation
BookingSystem
Theater
Showtime
Movie
Reservation
Complete Code Implementation
Verification
Test Case 1: Successful booking flow
Test Case 2: Concurrent booking - exactly one succeeds
Test Case 3: Cancellation releases seats correctly
Test Case 4: Partial booking fails atomically
Extensibility
How would you support dynamically adding and removing showtimes, movies, and theaters?
How would you handle temporary seat holds during checkout?
What is Expected at Each Level?
Junior
Mid-level
Senior
Purchase Premium to Keep Reading
Unlock this article and so much more with Hello Interview Premium
Currently up to 20% off
Hello Interview Premium
Reading Progress
On This Page
Understanding the Problem
Requirements
Clarifying Questions
Final Requirements
Core Entities and Relationships
Final Entities
Class Design
BookingSystem
Theater
Showtime
Movie
Reservation
Final Class Design
Implementation
BookingSystem
Theater
Showtime
Movie
Reservation
Complete Code Implementation
Verification
Extensibility
How would you support dynamically adding and removing showtimes, movies, and theaters?
How would you handle temporary seat holds during checkout?
What is Expected at Each Level?
Junior
Mid-level
Senior
Schedule a mock interview
Meet with a FAANG senior+ engineer or manager and learn exactly what it takes to get the job.
