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?