System requirements
Functional:
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
- Search events
- View details of an event
- Book a ticket
Non-Functional:
List non-functional requirements for the system...
- Prioritize availability for search, while prioritize consistency for ticket booking
- Should be able to handle traffic spike for popular events
- Search latency should be less than 500ms
Capacity estimation
Estimate the scale of the system you are going to design...
Assume 1 user does 10 searches per day: 50000 daily active users * 10 searches / 100000 seconds = 5 search / second
API design
Define what APIs are expected from the system...
GET /v1/search/event?date={date}&lat={lat}&lng={lng}&performer={performer_name}&anchor={anchor_id}&size={size}
GET /v1/event/{event_id}
POST /v1/reserve
{
ticket_id
}
POST /v1/payment
{
reservation_id
}
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...
Mysql / postgres relational db
for ACID guarantee because we have transaction involved in the system
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...
For search: client calls GET /v1/search API, api gateway does authentication / rate limiting and routes the request to the search server, search server queries datastore to get the eligible events meeting search conditions and sends the response to the client
For viewing event details: User clicks the events they are interested from the search returned result list, the client calls the GET /v1/event API to get the details of the event, api gateway routes the request to the event server, event server queries db to get the details of the event and returns details to client, client then show the details to user
For reserve: User selects seat and clicks reserve, client calls the POST /v1/reserve api, api gateway routes the request to reservation server, reservation checks whether the seat is already reserved by other user, if not, write the reservation record to db and returns the reservation id to client. We will talk about how to avoid duplicate reservation and the status transition of a reservation in the deep dive section.
For payment, once user clicks Pay button, client calls the POST /v1/payment API, api gateway routes the request to the reservation server, reservation server calls a third party payment service provider like adyen/stripe to try the payment, and update the status of the reservaton accordingly, and return the payment result to usr.
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?