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?