Ticketmaster is a platform that enables users to discover, purchase, and manage tickets for live events such as concerts, sports, and theater. It connects event organizers with consumers while handling seat inventory, pricing, and digital ticket delivery.
Product Design Requirement
Functional Requirement
- Users should be able to view event details
- Users should be able to search events (by keywords)
- Users should be able to book tickets for an event
Non-Functional Requirement
- The system should prioritize availability for browsing and searching events, while enforcing strong consistency during ticket booking to prevent double booking.
- The system must handle high throughput, supporting up to 10M concurrent users during peak ticket release events.
- The system should provide low-latency responses for both event search and event detail views to ensure a smooth user experience.
Design Setup
Data Model
- Event: Represents a specific occurrence that users can attend, such as a concert, sports game, or show. It typically includes metadata like event name, date/time, associated venue, performers, and ticket availability.
- User: Represents a person interacting with the system, either browsing events or purchasing tickets. It stores user-related information such as account details, payment methods, and booking history.
- Booking: Represents a transaction where a user reserves or purchases one or more tickets for an event. It tracks the booking status (e.g., pending, confirmed, cancelled), total price, and links the user to the tickets.
- Ticket: an individual seat or entry pass for an event. A ticket is associated with a specific event and often a specific seat (for reserved seating), and includes details like price, seat number, and ownership.
- Venue: Represents the physical location where an event takes place, such as a stadium or concert hall. It includes details like address, capacity, and seating layout, which is critical for seat allocation and availability.
- Performer: Represents the artist, team, or group performing at the event. An event can have one or multiple performers, and this entity stores information such as name, category, and popularity.
API Design
-
For viewing event details, we expose a read endpoint like
GET /events/:eventID, which returns metadata such as venue, performers, schedule, and ticket availability. -
For searching events, we can provide an endpoint like
GET /events/search?q={keyword}&location=...&date=....
- For ticket booking, we introduce a write endpoint such as POST /bookings. The request includes the eventId, selected seats (or quantity), and user information. Unlike read APIs, this flow requires strong consistency to prevent double booking.
POST /bookings/:eventId -> bookingId { "ticketIds": string[], "paymentDetails": ... }