Ticketmaster

November 14, 2021 7:00 PM PST

---

This document summarizes a mock system design interview focused on the Ticketmaster platform. The discussion revolved around the design requirements, functional and non-functional specifications, and the proposed architecture for handling a large-scale ticket sales event.

Interview Details

• Interviewer: Unspecified
• Interviewee: Unspecified
• Target Level: L4 or low L5
• Duration: 1 hour

Requirements

Functional Requirements

• A large ticket sales event will start at a pre-set time.
• All tickets are the same (no difference in seating or content).

Non-Functional Requirements

• 100,000 tickets to sell.
• 10 million people want to buy tickets.
• P0: Buy ticket (limit of 2 tickets per user).
• P0: Buyers can see order status.
• P0: 1-hour session timeout for orders.
• P3: View tickets.

Audience Feedback

• Non-functional requirements were initially missing.

System Design

API Endpoints

• POST: /v1/tickets?q=number_items

  • Response: {status: "", callback: url} (possible statuses: fail, pending)

• POST: /v1/tickets/payment

  • Response: {status: } (possible statuses: Accepted, Rejected, Timeout)

Database Schema

• Ticket Table:

  • Uid: Primary Key
  • Item: Varchar
  • Total_quantity: Integer
  • Available_quantity: Integer
  • Price: Integer

• Order Table:

  • Uid
  • User_id
  • Payment_ref
  • Status
  • Creation_ts (can be used to cancel)
  • Quantity

System Design Diagram

• The design includes a MySQL database for strong consistency and a potential Redis cache for ticket availability.

Discussion Points

Scalability and Performance

• Anticipated traffic of 10 million users visiting the website.
• The ticket database will only have a few rows, making it manageable.
• If multiple ticket types are introduced, a caching layer (e.g., Redis) may be necessary.

Order Processing

1. User visits the website.
2. API gateway sends a request to the ticket service.
3. Ticket service checks Redis for available ticket count.
4. Ticket service places an order with the order service.
5. Order service updates the ticket count in the database.
6. Order service responds with success or failure.

Cache Management

• The cache is updated every 10 to 30 seconds.
• A batch job is responsible for updating ticket availability after order expirations.

Handling High Traffic

• Multiple replicas of the API gateway can handle up to 50,000 users each.
• Throttling mechanisms may be necessary to prevent abuse and manage high throughput.

Data Consistency

• Discussed the importance of maintaining accurate ticket counts and the potential for dirty reads.
• The need for a queuing service to ensure requests are processed in order was highlighted.

Session Management

• A session management service is required to handle order reservations.
• Orders should be locked for one hour, after which they can be released if not completed.

Feedback and Improvements

• Audience feedback emphasized the need for a robust design that can handle bursts of requests and ensure data consistency between Redis and MySQL.
• The importance of a clear strategy for managing high throughput and potential crashes was discussed.

Conclusion

The interview covered various aspects of designing a ticket sales system, focusing on scalability, performance, and data integrity. The discussions highlighted the complexities involved in handling a high volume of requests and the necessity of a well-structured architecture to ensure a seamless user experience.