Design an Online Ticketing System: LLD Guide

Alright, let's dive into how to design an online ticketing system, like BookMyShow. Think of it as building a Lego set: each piece has to fit just right. I'll walk you through the design, covering everything from the database to the API endpoints. Whether you're prepping for an interview or just curious, this is for you.

Why an Online Ticketing System?

Online ticketing systems are everywhere. They handle millions of transactions daily, from movie tickets to concerts. Designing one involves several challenges:

Scalability: Handling a massive number of concurrent users.
Concurrency: Preventing double-booking of seats.
Reliability: Ensuring transactions are processed correctly.
User Experience: Making the system easy to use.

I remember working on a project where we underestimated the concurrency issue. During a flash sale, we had double bookings, angry customers, and a support team on fire! That's when I understood the importance of solid LLD.

Core Components

Let's break down the core components of our ticketing system:

Event Management: Manages events, venues, and schedules.
Seat Management: Handles seat availability and booking.
User Management: Manages user accounts and profiles.
Payment Processing: Integrates with payment gateways.
Booking Management: Manages bookings, cancellations, and refunds.
Notification Service: Sends notifications to users.

Event Management

Event: Represents a specific event, like a movie or concert.
Attributes: event_id, name, description, start_time, end_time, venue_id.
Venue: Represents the physical location where the event takes place.
Attributes: venue_id, name, address, capacity.
Schedule: Represents the schedule of an event at a specific venue.
Attributes: schedule_id, event_id, venue_id, start_time, end_time, price.

Seat Management

Seat: Represents a specific seat in a venue.
Attributes: seat_id, venue_id, seat_number, row_number, seat_type.
SeatAvailability: Represents the availability of a seat for a specific schedule.
Attributes: availability_id, schedule_id, seat_id, is_available.

User Management

User: Represents a user of the system.
Attributes: user_id, username, password, email, phone_number.

Booking Management

Booking: Represents a booking made by a user for a specific schedule.
Attributes: booking_id, user_id, schedule_id, booking_time, total_amount, payment_status.
BookingSeat: Represents a seat booked for a specific booking.
Attributes: booking_seat_id, booking_id, seat_id.

Database Design

Here's a simplified version of the database schema:

sql
CREATE TABLE Events (
    event_id INT PRIMARY KEY,
    name VARCHAR(255),
    description TEXT,
    start_time DATETIME,
    end_time DATETIME,
    venue_id INT
);

CREATE TABLE Venues (
    venue_id INT PRIMARY KEY,
    name VARCHAR(255),
    address VARCHAR(255),
    capacity INT
);

CREATE TABLE Schedules (
    schedule_id INT PRIMARY KEY,
    event_id INT,
    venue_id INT,
    start_time DATETIME,
    end_time DATETIME,
    price DECIMAL(10, 2)
);

CREATE TABLE Seats (
    seat_id INT PRIMARY KEY,
    venue_id INT,
    seat_number INT,
    row_number INT,
    seat_type VARCHAR(50)
);

CREATE TABLE SeatAvailability (
    availability_id INT PRIMARY KEY,
    schedule_id INT,
    seat_id INT,
    is_available BOOLEAN
);

CREATE TABLE Users (
    user_id INT PRIMARY KEY,
    username VARCHAR(255),
    password VARCHAR(255),
    email VARCHAR(255),
    phone_number VARCHAR(20)
);

CREATE TABLE Bookings (
    booking_id INT PRIMARY KEY,
    user_id INT,
    schedule_id INT,
    booking_time DATETIME,
    total_amount DECIMAL(10, 2),
    payment_status VARCHAR(50)
);

CREATE TABLE BookingSeats (
    booking_seat_id INT PRIMARY KEY,
    booking_id INT,
    seat_id INT
);

Relationships

One-to-Many: One event can have multiple schedules. One venue can have multiple seats.
Many-to-Many: One booking can have multiple seats. One schedule can have multiple seat availabilities.

API Endpoints

Here are some key API endpoints:

GET /events: List all events.
GET /events/{event_id}: Get details of a specific event.
GET /venues/{venue_id}: Get details of a specific venue.
GET /schedules/{schedule_id}: Get details of a specific schedule.
GET /seats/{venue_id}: List all seats for a venue.
GET /seat-availability/{schedule_id}: Get seat availability for a schedule.
POST /bookings: Create a new booking.
GET /bookings/{booking_id}: Get details of a specific booking.
PUT /bookings/{booking_id}/cancel: Cancel a booking.

Example: Create a Booking

http
POST /bookings
Content-Type: application/json

{
    "user_id": 123,
    "schedule_id": 456,
    "seat_ids": [789, 101, 112]
}

Concurrency Handling

To prevent double-booking, we need to handle concurrency. Here are a few strategies:

Pessimistic Locking: Lock the seat availability record before booking.

java
// Example using JDBC
String sql = "SELECT * FROM SeatAvailability WHERE schedule_id = ? AND seat_id = ? FOR UPDATE";

Optimistic Locking: Use a version number to check if the record has been modified.

java
// Example using a version column
UPDATE SeatAvailability SET is_available = false, version = version + 1
WHERE schedule_id = ? AND seat_id = ? AND version = ?;

Transactions: Ensure all operations are atomic using transactions.

java
// Example using Spring
@Transactional
public void bookSeats(int scheduleId, List<Integer> seatIds, int userId) {
    // ...
}

System Architecture

Here’s a high-level architectural diagram:

[React Flow UML diagram would be inserted here]

Load Balancer: Distributes traffic across multiple servers.
API Gateway: Handles routing, authentication, and rate limiting.
Application Servers: Run the application logic.
Database: Stores the data.
Cache: Caches frequently accessed data.
Message Queue: Handles asynchronous tasks like sending notifications.

We can use technologies like:

Load Balancer: Nginx, HAProxy
API Gateway: Kong, Tyk
Application Servers: Spring Boot, Node.js
Database: MySQL, PostgreSQL
Cache: Redis, Memcached
Message Queue: RabbitMQ, Kafka, Amazon MQ

Speaking of message queues, have you ever wondered how Amazon MQ or RabbitMQ work in detail? It's all about asynchronous communication and handling tasks in the background.

Scalability and Performance

To handle scalability and performance, consider:

Caching: Cache frequently accessed data like event details and seat availability.
Database Sharding: Split the database across multiple servers.
Replication: Replicate the database for read-heavy operations.
Load Balancing: Distribute traffic across multiple servers.
Asynchronous Tasks: Use message queues for tasks like sending notifications.

Internal Linking Opportunities

For more on system design, check out Coudo AI's System Design section.

Also, explore low level design problems for hands-on practice.

FAQs

Q: How do you prevent seat double-booking?

Use pessimistic or optimistic locking in database transactions.

Q: What database should I use?

MySQL or PostgreSQL are good choices for relational databases.

Q: How do you handle payment processing?

Integrate with payment gateways like Stripe or PayPal.

Q: How do you scale the system?

Use caching, database sharding, and load balancing.

Wrapping Up

Designing an online ticketing system is a complex task. We covered the core components, database design, API endpoints, concurrency handling, and system architecture. I hope this guide helps you in your low-level design interviews and real-world projects. If you want to practice more, check out Coudo AI for machine coding challenges. Keep pushing forward, and you'll master LLD in no time!

So, next time you book a movie ticket, you'll know what's happening behind the scenes! Remember, solid low-level design is the key to building robust systems that can handle the load.