Designing a Scalable Online Movie Ticket Reservation System

Introduction

The online ticketing market has evolved to include mobile payments, electronic tickets, real‑time analytics, AI‑driven recommendations, and risk management. Building a robust ticket reservation system requires addressing privacy, fraud prevention, and user experience challenges.

System Overview

DaMai (大麦网) is a leading Chinese ticketing platform offering event search, online purchase, e‑tickets, seat selection, refunds, and payment integration. Similar services include Maoyan, Yongle, BookMyShow, and Ticketmaster.

Functional Requirements

List partner cinemas by city.

Show movies currently playing in a selected city.

Display cinemas and showtimes for a chosen movie.

Allow users to select a show, view seat layout, and reserve seats.

Distinguish available from already‑reserved seats.

Hold selected seats for five minutes before payment.

Provide a fair, first‑come‑first‑served waiting queue when seats become available.

Non‑Functional Requirements

High concurrency: the system must handle many simultaneous reservation attempts gracefully and fairly.

Financial security and ACID‑compliant database transactions.

Design Considerations

No user authentication is assumed for simplicity.

All‑or‑nothing reservation: a user either gets all requested seats or none.

Limit each reservation request to a maximum of ten seats to prevent abuse.

Expect traffic spikes for popular movies; the system must scale and remain highly available.

Capacity Estimation

Assuming 30 billion page views per month and 10 million tickets sold monthly, with 500 cities, 10 cinemas per city, 2 000 seats per cinema, and two shows per day, the raw data footprint is roughly 2 GB per day (≈ 3.6 TB for five years).

API Specification

Both SOAP and REST interfaces can expose the core functionality. Example API signatures:

SearchMovies(api_dev_key, keyword, city, lat_long, radius, start_datetime, end_datetime, postal_code, includeSpellcheck, results_per_page, sorting_order)

Parameters include developer key, search keywords, geographic filters, time windows, pagination, and sorting options.

ReserveSeats(api_dev_key, session_id, movie_id, show_id, seats_to_reserve[])

The reservation call returns a JSON status indicating success, full show, or temporary failure due to competing reservations.

Database Design

One city can have many cinemas; each cinema contains multiple halls.

Each movie has multiple shows; each show can have many reservations.

Users may have multiple reservations.

Key tables include Booking (with Status = Reserved(1) or Booked(2) and a timestamp) and Show_Seat (seat status).

Top‑Level Architecture

The web server manages user sessions, the application server handles ticketing logic, a relational database stores persistent data, and a cache server assists with fast seat‑availability checks.

Component Design

The reservation workflow consists of:

User searches for a movie.

User selects a movie.

System shows available showtimes.

User picks a show.

User chooses seat quantity.

If seats are available, a seat‑map is displayed; otherwise the user enters a waiting flow.

System attempts to reserve the selected seats.

If reservation fails, options include showing an error, returning to the seat map, or placing the user in a waiting queue (max one hour).

After a successful reservation, the user has five minutes to complete payment; otherwise the seats are released.

ActiveReservationService & WaitingUserService

Two daemon services are introduced:

ActiveReservationService tracks live reservations, expires them after the timeout, and interacts with payment gateways.

WaitingUserService maintains a FIFO queue of users waiting for seats to become free, using a LinkedHashMap‑like structure keyed by ShowID.

Clients can use long‑polling to receive updates when seats become available.

Concurrency Control

SQL transactions with SERIALIZABLE isolation ensure that no two users can reserve the same seat. Sample transaction:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;</code>
<code>BEGIN TRANSACTION;</code>
<code>-- Check that seats 54,55,56 for ShowID=99 are free</code>
<code>SELECT * FROM Show_Seat WHERE ShowID=99 AND ShowSeatID IN (54,55,56) AND Status=0;</code>
<code>-- If three rows returned, update them and the Booking table</code>
<code>UPDATE Show_Seat SET Status=1 WHERE ...;</code>
<code>UPDATE Booking SET ... WHERE ...;</code>
<code>COMMIT TRANSACTION;

Fault Tolerance

If either daemon crashes, the system can recover active reservations from the Booking table (status Reserved). A primary‑secondary deployment can provide failover for the services. Waiting users are not persisted, so a crash of WaitingUserService would lose the queue unless a standby is configured.

Data Partitioning

Sharding can be performed by MovieID (all shows of a movie on one server) or, more evenly, by ShowID. Consistent hashing distributes both ActiveReservationService and WaitingUserService instances across multiple application servers based on ShowID, ensuring that all activity for a given show is handled by the same subset of servers.

Conclusion

The design balances functional richness with scalability, high concurrency, and fault tolerance, providing a solid blueprint for building a production‑grade online movie ticket reservation platform.