System requirements
Functional:
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
- Showing list of events along with description and dates and estimate availability.
- Book one or multiple events on different time for multiple customers under same account
- Customers can edit/cancel their events that falls on event's policy
- Event hosts can manager their events such as refund/cancellation/set oversell capacity
Non-Functional:
List non-functional requirements for the system...
- consistency
- availability
- low latency
in this system, availability has higher priority than consistency because event host can resolve occasion conflicts or overselling, latency is crucial but we can treat this with lower availability because most customers can be patient to book a ticket.
Capacity estimation
Estimate the scale of the system you are going to design...
//the peak QPS for booking ticket can be super high when there is a start of a event
//we can assume over 200,000 QPS during peak for writing and around 20k during non peak time.
//the read will still be higher than write with an 80 % read ratio
each create will consist below data
32 bytes id
64 bytes name
32 bytes event id
so it will be 128 bytes * 200k writes ~= 25.6 mb per second which is about 0.8 pt per year.
if we need to host 200,000 qps, we need to about around 100 4gb ram instance
API design
Define what APIs are expected from the system...
// customer view
get /api/list?
get /api/event/
post /api/event/
// event host
get /api/list?
get /api/event/
post /api/create/event EventInfo
update /api/event/
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...
// User table
user_id
name
password
role
create_time
update_time
// Event table
event_id
host_io
title
description
event_date
capcity
oversell_capacity
create_at
update_at
//Booking table
booking_id
user_id
event_id
ticket_count
booking_date
price
status
//Event policy table
policy_id
event_id
cancell_allowed
refund_policy
policy_created_at
policy_updated_at
flowchart TD
A[User Interface] -->|Interacts with| F[API Gateway]
F -->|Route Requests| B[Booking System]
B -->|Sedns Requests| D[Paymemt service]
B -->|Sends Requests| C[Ticketing Service]
C -->|Sends Requests| E[Notification Service]
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...
flow:
User interact with event service to find events
User book event with the event id get from events
The booking service will check avaliblity from event service
then route user to the payment gateway and send booking request to ticket services
the ticket service will create ticket for user once the payment is processed.
the ticket service will send request to notificatio service to notify users
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...
//Booking system
- create manage bookings information
- send request to ticket system to request tickets
- manage payments such refund/cancellation
//ticket system
- create ticket for user base on the request
- allow user to view/download tickets
- validate tickets
//Event system
- allow user to view/manage event
- capacity management
- refund or cancellation management
- analytics and reporting
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
The system will use mysql to manage the tickets but without the foregin key. the reason is that event we have high write but to support feature like oversell require strong Consistency, so nosql will not give us more advantage.
To increase the performance we may need to share the database by events and utilze dns or caching service to distrubute event related information
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
if the booking system is done, the user will be able to view the events
the bottleneck will be if something changes but the event server is down, the user may still be able to book but the event policy may not reflect. my decison will be that if event system is down, the booking system will be locked temporarily but the user can still manage the purchased tickets.
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?