System requirements

Functional:

• vendors can list events
• each event has a number of tickets
• tickets can have associated seats
• tickets can be set to release at a time
• customers can buy tickets

Non-Functional:

• consistency is the most important requirement - tickets cannot be sold twice
• scalability - the system should be able to handle surges in traffic during peak times
• fault tolerance - the system needs to have the ability to recover data in case of incidents

Capacity estimation

• We need go be able to support tens of thousands of visitors to the site during peak traffic hours

API design

for events:

• POST/PUT/DELETE (edit and delete are gated) - authx

for tickets:

• POST/DELETE (delete is gated)

for ticket sales:

• POST/UPDATE (we need to keep a record of the sales, not just update the record - ticketholder has the most current entry associated with the ticket

when a ticket is purchased we also need backing payment infrastructure

Database design

users:

id

name, address, etc

vendor:

id

config for payment details

tickets:

id

category

seat number (can be null)

event_id

ticket_categories:

id

desc

event:

id

desc

time of event

metadata

venue_id

venue:

id

address

details

ticket sales:

user_id

ticket_id

status

High-level design

Frontend

API Gateway:

JWT based auth

load balancing

throttling to handle excess load during peak times

API

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?