System requirements

Functional:

• Book tickets
• View events
• Search for events

Non-Functional:

• Strong consistency for booking tickets
• High availability for search and view events
• Read >> write
• Scalability to handle surges from popular events
• Low latency search

-----

Out of scope:

• GDPR compliance
• Fault tolerance

Capacity estimation

• DAU: 100k
• Read QPS: 500k / 3600 / 24

API design

GET /events

GET /event/eventId. -> event & details

GET /search?term={term}&location={location}&date={date}

POST /booking/reserve

header: JWT | sessionToken

body: { ticketID }

POST /booking/confirm

header: JWT | sessionToken

body: { ticketID,

paymentDetails (stripe)}

GET /booking/ticketID

Database design

Event db:

Event:

• id
• venue_id
• performer_id
• name
• date
• desc

Venue:

• id
• location
• seat_map

Performer:

• id
• ....

Ticket

• id
• event_id
• seat
• price
• status: available, reserved, booked
• reserved_at
• user_Id
• booking_id

High-level design

API Gateway:

• Authentication
• rate limiting
• routing

Ticket Lock(Redis):

• {ticket_id: true} TTL= 10

Elasticsearch (aws opensearch: node query caching)

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?