4. Ticketmaster System Design

🎟️ What is Ticketmaster?
Ticketmaster is an online platform for purchasing tickets to live entertainment events, including concerts, sports, and theater.


Understanding the Problem

Ticketmaster needs to handle millions of users searching for and booking tickets simultaneously. Designing a system to ensure availability, consistency, and scalability is critical.


Functional Requirements

  1. Users should be able to view events.
  2. Users should be able to search for events.
  3. Users should be able to book tickets to events.

Below the line (out of scope):

  • Users should be able to view their booked events.
  • Event coordinators should be able to add events.
  • Dynamic pricing for popular events.

Non-Functional Requirements

  1. The system should prioritize availability for searching & viewing events but prioritize consistency for booking (no double bookings).
  2. The system should be scalable to handle high traffic during popular events.
  3. Low latency in search (< 500ms).
  4. The system should support high read throughput.

Below the line (out of scope):

  • GDPR compliance.
  • Fault tolerance.
  • Secure transactions and regular backups.

Defining Core Entities

  1. Event: Stores event details like date, description, type, and performer.
  2. User: Represents individuals interacting with the system.
  3. Performer: Represents artists or teams.
  4. Venue: Stores location and seating capacity.
  5. Ticket: Tracks event seat availability and pricing.
  6. Booking: Tracks user ticket purchases and payment statuses.

API Design

  1. View Event
    GET /events/:eventId
    Returns event details, including venue, performers, and available tickets.

  2. Search Events
    GET /events/search?keyword={keyword}&start={start_date}&end={end_date}&pageSize={page_size}&page={page_number}
    Returns a list of events matching the search criteria.

  3. Book Tickets
    POST /bookings/:eventId
    Input: Ticket IDs and payment details.
    Output: A booking ID upon successful reservation.


System Design Overview

  1. Event Viewing Service
    • Client requests for viewing an event are routed via an API Gateway.
    • The Event Service handles requests by querying the Event DB for event details, performers, and venue info.
    • The client receives the event details along with a seat map.
  2. Search Service
    • Client search requests are routed through the API Gateway to the Search Service.
    • The service queries the Event DB for events matching the search parameters and returns results to the client.
  3. Booking Service
    • The booking process starts with a POST request to the Booking Service, which checks ticket availability and processes payment.
    • The Payment Processor (e.g., Stripe) confirms the payment, and tickets are marked as “sold” in the Ticket DB.

Database Design

  • Events DB: Contains tables for events, performers, and venues.
  • Tickets DB: Stores seat information, ticket status, and links to the booking data.
  • Bookings DB: Tracks all user bookings, payment status, and ticket allocations.

System Scalability

  • Microservices: Event, search, and booking services are split into microservices to ensure scalability.
  • API Gateway: Handles authentication, rate limiting, and routing to respective services.
  • Database Transactions: The booking process uses database transactions to prevent double bookings, ensuring ACID compliance.

Conclusion

This design ensures Ticketmaster can handle a high volume of read-heavy requests for viewing and searching events, while providing transactional consistency for ticket bookings. The system is highly available, scalable, and resilient to high traffic scenarios.