Ticketmaster - Ticket Booking System

Functional requirements

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

Out of scope: (Check with interviewer if they want to move any of this to the functional requirements)

1. User should be able to view their booked events
2. Admins or event coordinator should be able to add event
3. Popular events should have dynamic pricing

Non functional requirements

1. System should prioritise availability for searching & viewing events, but consisteny for booking events
2. System should be scalable and handle high throughput for popular event (max 10 million user 1 event)
3. Search latency should be low (< 500ms)
4. System is read heavy, need to be able to support high read throughput (100:1)

Out of scope: (nice to have)

1. System should protect user data and adhere GDPR (data encryption, anonymize)
2. System should be fault tolerant
3. System should provide secure transactions for purchases
4. System should be well tested and easy to deploy
5. System should be regular backups

Core entities

1. Event: store the information about events i.e date, description, type
2. User: represents individual iiteracting with the system
3. Performer: artist name, company etc
4. Venue: venue name, address, seat map, seat layout
5. Ticket: contains the information about the events i.e event ID, seat details, pricing
6. Booking: User ticket purchase detail i.e user id, ticket ids

[!note] Booking can also be combined with ticket
We can also combine booking with ticket itself, however in the case where 1 user booking contains multiple tickets, it could be useful

API

1. User to view event

GET /v1/events/:eventId -> Event & Venue & Performer & Ticket[]


2. User can search for event

GET /v1/events/search?keyword={keyword}&start={start_date}&end={end_date}&pageSize={page_spize}&page={page_number} -> Event[]


3. User can purchase the ticket for the event

POST /v1/events/:eventId/booking -> Booking[]
{
    ticketIds: string[]
    paymentDetails: ...
} 

[!note]
In production system, normally we dontsend the paymentDetails as the post request, instead the user will send payment data to 3rd party payment system i.e Stripe, which we will use the transactionId provided by the user to validate against Stripe API

High level design

1) User should be able to view the events

User will make a GET /v1/events/:eventId to API gateway which route the request to Event Service. The Event Service will then query our database for information and display back to the user

2) User should be able to search for events

In here, we can create a search service to handle searching. We technically can put in the same service as well but we want to CQRS (Command Query Responsibility Segregation) to scale easily — hence the split of search service and event service.

User can make a GET /v1/events/search?keyword={key_word}... to our API Gateway, the API gateway will route this to our search service. If necessary, we can have a layer of load balancer in the front to scale out the search service as well.

Search service then query the database and return us back the event information for the client.