System requirements


Functional:

  1. User registration and login
  2. Movie listings and showtimes
  3. Seat selection and reservation
  4. Payment processing
  5. Email confirmation
  6. Ticket generation



Non-Functional:

  • highly available
  • eventual consistency is OK for searching and event details but not for booking seats
  • Reads >> Writes




Capacity estimation


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)









API design

REST


POST /signup

body: {username, password}


POST /login

body: {username, password}


GET /search?q=Ghost&city=Chico

response: {events: [Events]}


POST /book/

body: [ticketIds]

  • locks ticket for likited time to allow user to complete payment


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



Database design

User

  • id
  • username
  • password
  • location


Event

  • id
  • ownerId * FK to user table
  • name
  • venue
  • type
  • time


Ticket

  • id
  • seat
  • eventId * FK to event table
  • holderId * FK to user table




High-level design


  • Web/Mobile clients will use provided APIs
  • APIs point to our gateway, which is responsible for SSL termination, rate limiting, routing, authentication/authorization. Gateway will route request to appropriate microservice
  • User micro service - manage user data
  • Search micro service - handle search requests
  • Search indexing service
  • Events micro service - handle event creation and tickets creation, queues new events and updates to seach indexing service
  • Booking micro service locks tickets and emit tickets once payment is complete, roll back if lock timeout in a pessimistic way







Request flows

Search:

  • user types query in search box and sends request to /search API
  • gateway routes request to Search service
  • search service queries elastic search and returns matches to user


Booking:

  • user clicks on event from search results and lands on event detail page showing available seats
  • client makes request to /events/{eventId} to get event details and available seats
  • requests hits gateway followed by Events microservice
  • Events microservice hits Events/Tickets DB to get details and available seats that are not locked
  • user chooses seats and clicks to book
  • client makes request to /reserve with ticketIds in body
  • request hits gateway followed by Bookig service
  • Booking service will try to lock ticketIds on Zookeeper
  • if successful
  • redirect user to payment page
  • if payment is successful Booking service will update the holderIds on the Tickets table
  • if payment times out or user navigates away the lock will exxpire and the tickets will be available again for others to by
  • return error to user and redirect to event page




Detailed component design


  • Microservices handling API requests are stateless and can be scaled horizontally



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?