Low Level Design - Design a Movie Ticket Booking System

Requirements

1. Admin can add or edit movies.
2. Admin can add cinema halls.
3. Admin can add movie shows.
4. Customers can browse movies.
5. Customers can select cinema halls, choose seats, and book tickets.

Class Diagram

User
----------------
- userId: String
- name: String
- email: String
- password: String
------------------
+ register()
+ login()
+ updateProfile()

Seat
----------
- row: int
- number: int
- status: SeatStatus
- seatType: SeatType

Auditorium
----------
- id: String
- seats: Seat[][]
-----------------
+ updateLayout()

CinemaHall
----------
- id: String
- address: Address
- auditoriums: List<Auditorium>
-------------------------------
+ addCinema()
+ updateCinema()

Movie
------------
- id: String
- name: String
- duration: Integer
- genre: String
- type: MovieType
-----------------
+ addMovie()
+ updateMovie()

MovieShow
------------
- id: String
- auditorium: Auditorium
- startTime: LocalDateTime
- endTime: LocalDateTime
------------------------
+ scheduleMovie()
+ updateShowtime()

Booking
------------
- user: User
- movieShow: MovieShow
- seats: List<Seat>
-------------------
+ bookTickets()
+ cancelBooking()

enum SeatStatus
AVAILABLE / UNAVAILABLE / OCCUPIED

enum SeatType
RECLINER / NORMAL

enum MovieType
2D / 3D / 4D

Design Choices

Factory Pattern

As there can be multiple User Types, (CUSTOMER / ADMIN / etc.,) we can use Factory Pattern to create different types of users adhering to the principle of creating objects without exposing the creation logic.

Strategy Pattern

Different pricing strategies for ticket booking could be implemented with the Strategy pattern. This could be useful for promotional discounts, peak pricing, or member discounts.

Decorator Pattern

We can use the Decorator Pattern to add additional features to a ticket at run-time, like snacks, or meal combos etc.

Observer Pattern

For sending notifications to users about booking confirmations, cancellations, or changes in showtime, the Observer pattern can be used where the user subscribes to notifications.

State Pattern

The booking process has different states (selecting seats, payment processing, confirming booking). The State pattern can manage these states and transitions between them.

Database Schema

User
---------------
id: varchar PK
name: varchar
email: varchar
passwordHash: varchar

CinemaHall
----------
id: varchar PK
name: varchar
address: varchar

Auditorium
--------------
id: varchar PK
cinemaId: varchar FK
seatLayout: jsonb

Movie
--------------
id: varchar PK
title: varchar
duration: varchar
genre: varchar

MovieShow
--------------
id: varchar PK
movieId: varchar FK
screenId: varchar FK
startTime: timestamp

Booking
--------------
id: varchar PK
userId: varchar FK
movieId: varchar FK
seatIds: jsonb

API Specification

Book Tickets

• API: POST /api/bookings
• Request Body:
  • userId: String
  • movieShowId: String
  • seats: List<\String>

• Response Body:
  • bookingId: String
  • status: String
  • paymentStatus: String

Cancel Booking

• API: POST /api/bookings/{bookingId}/cancel

• Response Body:
  • status: String

Add Cinema

• API: POST /api/cinemas
• Request Body:
  • name: String
  • address: String
• Response Body:
  • cinemaId: String
  • status: String