设计一款在线售票平台

难度: hard

想象一下，你正在制作一个数字售票解决方案，用于电影票的销售，类似于Ticketmaster或BookMyShow的功能。

Solution

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
flowchart TD
    B[Web/Mobile clients] --> C[Gateway]
    C --> D[Search]
    C --> E[User]
    C --> I[Events]
    C --> F[Booking]
    D --> G[Elastic search]
    E --> H[User DB]
    I --> J[Events/Tickets DB]
    I --> G
    F --> J
    F --> K[Zookeeper]

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?


得分: 9