OOD Interview: Movie Ticket Booking System (BookMyShow)

Tier: 3 — Medium Time target: 35–45 minutes Patterns: Strategy, Observer, Singleton, State

---

Phase 1: Requirements & Use Cases

Interviewer: Let's design a movie ticket booking system like BookMyShow. Where would you start?

Candidate: I want to nail down the scope before touching any classes. Let me walk through actors and use cases, then we can align.

There are two primary actor groups. Customers browse movies, pick showtimes, select seats, pay, and occasionally cancel. Admins — theater managers — manage the catalog: adding cinemas, halls, movies, and shows.

Core use cases I'd prioritize:

1. Search movies by title, genre, language, city
2. View available showtimes for a movie
3. Browse available seats for a show
4. Select and temporarily reserve seats
5. Complete payment to confirm booking
6. Cancel a booking and release seats
7. Admin: add/remove movies, halls, shows

WHY: Separating customer-facing flows from admin flows immediately clarifies which classes need to be read-heavy versus write-heavy. This shapes our locking strategy later.

Interviewer: Should guests be able to book without registering?

Candidate: I'd distinguish browsing from booking. Guests can search movies and view showtimes without an account — that keeps the funnel wide. But to book a seat they must authenticate, because we need a contact for the ticket and payment identity. This maps to a Guest role that can only invoke read operations, and a Customer role for transactional operations.

WHY: Allowing anonymous browsing is standard UX and requires no changes to the core booking domain model — we just guard transactional…