System requirements

Functional:

Users

• Register user (email, password, Person)
• Login (email password)
• Delete account (user id)

Events

• Search event (location, date, category, person)
• Seat Selection (eventId, seatId)
• Change Seat(reservationId, new seatId)
• Create event (location, date, category, person)

Payment

• AddToShoppingCart(eventId, seatId)
• UpdateShoppingCart(reservationId)
• DeleteShoppingCart(reservationId)
• PayShoppingCart(reservationId)
• CancelReservation(reservationId)

Notification

• NotifyUser(reservationId)

Non-Functional:

• Scalable
• Consistency over availability

Capacity estimation

DAU: 50,000

Daily event search: 4

Daily new event: 1,000

Daily sign up: 5000

Daily read = 50,000 * 4 = 200,000 req/day

Avg Reqs per Second = 200,000 / 90,000 = 2

Peak event read= 2* avg Reqs per Second = 4

Avg create per second = 1,000 / 90,000 = .1 = 10 sec/event

Peak event create= 5 sec/event

Storage:

Event Data Size: 36B (eventId) + 100B(location) + 25B (date) + 4Byte(integer representation category) + 100 B (performer) + 1000B (description) + 100B(event name) + 4Byte (integer ticket price) + 4Byte (integer ticket total) + 4 Byte (integer ticket sold) + 4 Byte ( Integer seat number )

= 1375 ~ 1.4KB

5yr = 1.4KB * 1000 * 365 * 5 ~ 1.4 K * 1000 * 2000 ~ 2.8 T

Assume user event data consist of user id, eventId, array of seats id (Assume avg 2 tickets are being purchased)

= 36B + 36B + 2 * 4B = 80B

5yr = 80B * 5000 * 365 * 5 ~ 80B * 5000 * 2000 ~ 800G

API design

Users

• Register user (email, password, Person(Name, age etc))
• Login (email password)
• Delete account (user id)

Events

• Search event (location, date, category, person)
• Seat Selection (eventId, seatId)
• Change Seat(reservationId, new seatId)
• Create event (location, date, category, person)

Payment

• AddToShoppingCart(eventId, seatId)
• UpdateShoppingCart(reservationId)
• DeleteShoppingCart(reservationId)
• PayShoppingCart(reservationId)
• CancelReservation(reservationId)

Notification

• NotifyUser(reservationId)

Database design

UserDB contains userId, email, password and it's for user activities

EventDB contains all event related information can be created by registered users

SeatDB table that connects EVENT and USER when user attends an event

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?