Loading...
QPS:
1e4 concurrent users at peak hours
say a user searches for 5 events per visit on average
1e6 DAU
Search QPS: 1e6 * 5 / 1e6(~number of secs in a day)=5QPS average
At peak say the user spends 10min on the site and does 5 searches:
1e4 * 5 / 500 = 5e4/5e2 = 1e2
Peak search QPS: 100 QPS
50 events * 200 seats we have 1e4 tickets to sell per period
say venues are open for 12 hours and each event is 2 hours
gives 6e4 bookings per day
say only half of people that start the booking process finish it and we're able to sell out all events
Booking/payment/email notification/ ticket gen QPS: 6e4 / 1e6 6e-2 QPS
Storage
Say each event requires 1MB of data
50 events per period * 6 periods per day = 300 events per day
Say we need to store events for 10 years
300 * 365 * 10 = 9e4 events * 1MB = 9e4 * 1e6 ~ 1e11 = 100GB
For event tickets table we just multiply by 200 = 20 TB
Search index
Say we can search events for the next 3 months
300 * 100 = 3e4 events indexed at a time
1kB per search index record gives
1e3B * 3e4 = 3e7 = 30MB (tiny)
REST
POST /signup
body: {username, password}
POST /login
body: {username, password}
GET /search?q=Ghost&city=Chico
response: {events: [Events]}
POST /book/
body: [ticketIds]
Payments will be handled with a third party integration with something like Block. All APIs require user to be logged in, except for /login /logout and /signup
User
Event
Ticket
Search:
Booking:
Explain any trade offs you have made and why you made certain tech choices...
Try to discuss as many failure scenarios/bottlenecks as possible.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?