Movie Ticket Booking System

• A movie ticket booking system allows customers to purchase theatre seats online, browse movies, and book seats from anywhere.

Functional Requirements:

• List cities with affiliated cinemas.
• Display movies released in a selected city.
• Show cinemas running a selected movie and available show times.
• Allow users to choose a show and book tickets.
• Display the seating arrangement, with users able to select seats.
• Distinguish available seats from booked ones.
• Hold seats for users for five minutes before payment.
• Allow users to wait for seats that might become available.
• Service waiting customers in a first-come, first-served manner.

Non-Functional Requirements:

• Handle high concurrency gracefully and fairly.
• Ensure the system is secure and the database is ACID compliant due to financial transactions.

Design Considerations:

• The service does not require user authentication.
• Partial ticket orders are not supported; users get all desired tickets or none.
• Fairness is mandatory.
• Limit users to booking no more than ten seats at a time to prevent abuse.
• The system should be scalable and highly available to handle traffic spikes.

Capacity Estimation:

• 3 billion page views per month.
• 10 million tickets sold per month.
• 500 cities, each with ten cinemas on average.
• Each cinema has 2000 seats and two shows daily.
• Each seat booking requires 50 bytes of storage in the database (IDs, seat details, etc.).
• Movie and cinema info takes 50 bytes.
• Daily data storage: 2GB.
• Five-year data storage: 3.6TB.

System APIs

• SOAP or REST APIs can expose service functionality.

SearchMovies

• Used to search movie shows with parameters:
  • api_dev_key (string): API developer key for throttling.
  • keyword (string): Keyword to search on.
  • city (string): City to filter movies by.
  • lat_long (string): Latitude and longitude to filter by.
  • radius (number): Radius of the area in which we want to search for events.
  • start_datetime (string): Filter movies with a starting datetime.
  • end_datetime (string): Filter movies with an ending datetime.
  • postal_code (string): Filter movies by postal code / zipcode.
  • includeSpellcheck (Enum: “yes” or “no”): Include spell check suggestions.
  • results_per_page (number): Number of results to return per page (max 30).
  • sorting_order (string): Sorting order of the search result.
• Returns a JSON list of movies and their shows with details like MovieID, ShowID, Title, Description, Duration, Genre, Language, ReleaseDate, Country, StartTime, EndTime, and Seat availability and pricing.

ReserveSeats

• Used to reserve seats with parameters:
  • api_dev_key (string): API developer key.
  • session_id (string): User session ID to track reservation.
  • movie_id (string): Movie to reserve.
  • show_id (string): Show to reserve.
  • seats_to_reserve (number): An array of seat IDs to reserve.
• Returns a JSON status of the reservation:
  • "Reservation Successful".
  • "Reservation Failed - Show Full".
  • "Reservation Failed - Retry, as other users are holding reserved seats".

Database Design:

• Each city can have multiple cinemas.
• Each cinema will have multiple halls.
• Each movie will have many shows, and each show will have multiple bookings.
• A user can have multiple bookings.

High-Level Design:

• Web servers manage user sessions.
• Application servers handle ticket management.
• Data stored in databases and cache servers.

Detailed Component Design:

• Ticket booking workflow:

  • User searches for a movie and selects one.
  • Available shows are displayed.
  • User selects a show.
  • User selects the number of seats.
  • If seats are available, the user is shown a theatre map.
  • User selects seats, and the system tries to reserve them.

• If seats cannot be reserved:

  • The user is shown an error if the show is full.
  • If other seats are available, the user is taken back to the theatre map.
  • If no seats are available but some are in the reservation pool, the user can wait.
    • If seats become available, the user is taken to the theatre map.
    • If all seats get booked or there are fewer seats in the reservation pool than the user intends to book, the user is shown the error message.
    • The user can cancel waiting.
    • A user can wait a maximum of one hour.
  • If seats are reserved successfully, the user has five minutes to pay.

ActiveReservationsService:

• Tracks active reservations and removes expired ones.
• Keeps reservations of a show in memory using a Linked HashMap or TreeMap.
• Stores reservations in the Booking table in the database with a Timestamp column for expiry.
• Works with external financial services for payments.
• Signals WaitingUsersService upon booking completion or reservation expiry.

WaitingUsersService:

• Tracks all waiting user requests.
• Keeps waiting users of a show in memory using a Linked HashMap or TreeMap.
• Uses Long Polling to keep clients updated on their reservation status.

Reservation Expiration:

• ActiveReservationsService tracks expiry based on reservation time.
• A five-second buffer is added on the server to prevent early timeouts.

Concurrency:

• Transactions in SQL databases can prevent booking the same seat by multiple users.
• Transaction Isolation Levels can lock rows before updating.

Fault Tolerance:

• If ActiveReservationsService crashes, active reservations can be read from the Booking table.
• A master-slave configuration can allow a slave to take over.
• Master-slave setup for databases to make them fault-tolerant.

Data Partitioning:

• Partitioning by ShowID distributes load among servers better than partitioning by MovieID. -Web servers manage user sessions and communication. -Consistent Hashing allocates application servers for ActiveReservationService and WaitingUserService based on ShowID.
• When a reservation expires:
  • The database is updated.
  • The reservation is removed from the Linked HashMap.
  • The user is notified.
  • A message is broadcast to WaitingUserService servers to find the longest-waiting user.
  • A message is sent to the WaitingUserService server to process the request if seats are available.
• When a reservation is successful:
  • A message is sent to all servers holding waiting users of that Show.
  • Servers query the database to find available seats (a database cache helps).
  • Waiting users wanting more seats than available are expired.
  • WaitingUserService iterates through the Linked HashMap of waiting users.