System requirements
Functional:
view event
view available tickets and ticket price
buy ticket for an event
out of scope:
- search for events
Non-Functional:
- high consistency, when ticket is reserved/purchased, no one else can purchase it
- high scalable system, able to support popular events -> sudden surge of traffic
- read > write -> more ticket / event viewing than actual purchasing ticket
- fault tolerant -> able to gracefully handle if any steps during ticket purchasing fails
- latency: as fast as possible -> acceptable latency for purchasing ticket, low latency for viewing events / searching events
Capacity estimation
Estimate the scale of the system you are going to design...
100Million users
10 million DAU
- 10 reads per day -> 10 event viewing per day
- 1 purchase a day
storage:
user + event data: user data + user media + event data + event media: probably something really big, in the PB range
qps: 10M * 10 / 24 /3600 = 1000 read request / s , 100 write request / s
Peak QPS:
for popular events: 5*qps
API design
Define what APIs are expected from the system...
entities: user, events, artist, tickets, venue
lets focus on one event first and purchasing ticket
header: JWT/session token -> authentication
GET /event/search?name={name}&date_range={dates}&artist={artist}$event_type={type} etc etc
response {list of event_id}
GET /event/id
{event details, venue, tickets}
POST /reserve_ticket/
request: {ticket_id}
response: {reservation_expire_time}
POST /purchase_ticket/
request: {ticket_id}
response: {purchase_status}
Database design
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
entities: user, events, artist, tickets, venue
Use postgreSQL as my database choice
-> relationship between events and tickets
-> high read system, postgres is good choice here because we can read event data from replicas
ticket: all read and write go to one primary instance, this is to ensure strong consistency with ticket availability
there were be one replica used as fail over
events: can have multiple replicas, to improve performance of writes
ticket:
ticket_id
event_id
status: available, reserved, purchased
price
ticket_seat: 1a 2a etc etc
ticket_type: front_row, balcony, vip
user_id: nullable -> only populated for reserved or purchased_status
event:
event_id
venue_id
artist_id
date
etc etc
venue:
venue_id
address
venue_seat_map
user:
user_id
user metadata
etc etc
artist:
artist_id
artist metadata
etc etc
High-level design
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
Request flows
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
Detailed component design
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?