Requirements

Functional Requirements:

1. User can browse events in their city.
2. User can search events by artist, date range, name of event.
3. User can view details of a particular event.
4. User can book specific seats in a venue for particular event. Booking is confirmed after payment, which is part of external partner.

Non-Functional Requirements:

1. Consistency over availability for booking. Availability over consistency for browsing, search and view.
2. Low latency browsing and search(<100ms), for booking(<500ms) as consistency requirements preside over speed.
3. Fault tolerance and reliability is needed as double bookings are unacceptable
4. Scalability to support multiple regions and, for single city, 100k DAU. Also, system must absorb flash sale or blockbuster traffic for bookings.

Capacity Estimation

Assumption: Support 1000 cities across globe & no cross region operation support

Initial numbers:

1. 1M total users in single city
2. 100k DAU in single city.
3. Single user daily browses for events and their details about 100 times in a day
4. Single user on platform makes 1 bookings daily on average.
5. We only support events of next 1 year.
6. Daily average event are 10.

Derived numbers for single city:

1. Browsing traffic: 100,000 daily active users * 100 requests / day ~ 116 requests/sec
2. Booking traffic: 100,000 daily active users * 1 request / day ~ 1.16 requests/sec
3. Storage(events): 10 events * 365 days * 10 KB = 36.5 MB
4. Storage(user's bookings): 100,000 daily active users * 1 booking daily * 365 days * 1 KB = 36.5 GB

Peak traffic:

Assume 20% users become active at same time.

Booking traffic: 20,000 active users * 1 request/minute = 333 requests/second

Browsing traffic: 20,000 active users * 10 request/minute = 3333.3 requests/second

API Design

For all API requests, 401 on unauthorized or 404 on unknown endpoint or 400 on bad request.

GET /events

Response: Event[]

GET /events?filter=&sort_by=&pageLimit=&pageSize=

Response: Event[]

GET /events/{eventId}

Response: Event

GET /events/{eventId}/shows/{showId}/seats

Response: Seat[]

POST /bookings

Body: {

"event_id": int,

"seats": Seat[],

}

Response: {

"booking_id": int

}

POST /

NOTE: No view bookings endpoint as not part of the functional requirements.

For booking, we re-direct the user to payment link after reserving the seat for some TTL(10 minutes). User can retry the payment too and that is part of payment system. After payment is confirmed and the request is sent to our internal booking service, we reserve the seat for user after confirming TTL has not expired. TTL is auto released through redis expiry or background job. We will decide later.

High-Level Design

For each endpoint, individual flows are drawn. All external facing requests are sent through API gateway for authentication and authorization. We can double down on load balancer too as part of this component in future.

1. User sends requests to "Event service" which queries a specific Event in random order from Db.
2. When certain filteration or sorting is required we use search efficient Db like ElasticSearch to filter, sort and order the return response in paginated manner. The sync between ES and Event Db for new events or expiring older events is done through background sync backed by kafka or SQS.
3. For seatmap, we need each seatmap per event per venue. That requires it's separate Db with each seat's state containing details of reservation state, physical seat mapping, and booking_id associated with seat if needed.
4. For booking seat, request goes to Booking service and queries the Reservation Db for seat's lock and rejects if any of the mentioned seat is already locked. Changes their state in Seat Db conditionally on AVAILABLE state for seat, adds the reservation entry into Reservation expiry Db(Redis) with TTL of 10 minutes and adds a new Booking row, then re-directs user to STRIPE payment gateway. Payment result is committed back to Bookings service through re-direction and then if successful, seat Db's state is changed and Bookings Db's entry is also updated. If failure, it makes Bookings state to Payment failed. Seat is released only on expiry of TTL. Payment can be retried.
5. For seat write, we have to take care of contention, done through different techniques:
   1. Conditional write: doesn't work for multiple seat selection
   2. Optimistic locking: when low contention for seats
   3. Pessimistic locking: when high contention for seats -> matches consistency requirement. We don't have to over complicate as we can make sure a single event's hall's seat map sits in one instance of Db.
6. We can cache the hot events and their metadata in a city through Redis. We can add read replicas for Event Db as data is changed very less frequently but reads are high.
7. Notification and analytics system is opted out for now to keep scope limited to requirements only.

Database Design

Event

• event_id: int
• date: timestamp
• artist: string
• name: string

Venue

• venue_id: int
• name: string
• address: string

Show

• show_id: int
• event_id: int
• seat_ids: int[]

Seat

• show_id: int
• seat_id: int
• physical_seat: string
• reservation_state: Enum[VACANT, BOOKED]

Booking

• booking_id: int
• show_id: int
• seats: Seat[]
• payment_state: Enum[PENDING, DONE]

Considering our avg traffic and their peaks, SQL and NoSQL can both support the read/write ratios. What would be deciding factor over here is the data consistency guarantees needed.

For Event, Venue & Show, they don't have strict consistency or atomicity guarantees needed, so document Db or key value Db works best for them.

For Seat, requirements are:

1. seat should only be reserved by 1 user
2. seat should become vacant after TTL expiry

Such kind of reservation is best served by Redis as it is single threaded and provide key expiry per TTL. We keep the reservation_state in Redis and auto expire keys created in 10 min. Whenever a request comes in, first we check in Reservation Db(Redis) and then create entry in it if not present for reserving. Since lock is acquired, no one else will write to that row. Seat Db itself should be Sql as we need atomic writes on Seat db's reservation state using conditional write on state being VACANT when payment is done. So in essence when serving seat map, we need to exclude all BOOKED seats as well as reserved seats in redis. For doing this, we can store all entries for a event's show in single HashMap.

For Booking, we need ACID guarantees, so Sql Db.

All shards are by mapped by show_id.

Detailed Component Design

Seat hold lifecycle

1. User sends reservation request for list of seats in a show's venue.
2. Bookings service checks if any of the seat is present in Redis Hashmap for that show. Reject if found.
3. Then it adds new entry into Redis for those seats with 10 min TTL.
4. Redirect user to external payment system and wait for payment confirmation callback to Booking service.
5. Confirm payment by querying external payment system's endpoint using payment_id.
6. Update payment state in Bookings Db.
7. Update entry of all the seats in Seat Db to BOOKED.
8. Remove entries from Redis.

Serving seat map

When request comes in for seat map, we have seats that are BOOKED and seats that are on HOLD for reservation. To serve them, first it gets the non booked seats from Seat Db, and then gets locks in Reservation db's Hashmap for that specific show and filters out the present seats in Redis.

Serving hot events

For hot events like Taylor swift concert, we will have too high resource contention for individual seats.

Either we scale up the backend resources to serve all of those requests or only serve specific requests.

1. Reject requests as soon as all seats in HOLD or BOOKED state at API gateway level.
2. Scale up Seat Db and Event service to serve the high seatmap requests and re calculate seat map everytime for up to date information. Can still be stale as while calculating another person books a seat.

Remembering our original requirement of consistency over availability for booking, we have to reject request even if SeatMap showed non-vacant seat as vacant.

We will use hybrid approach here: Keep total left seat count for hot shows in API gateway specified using header when returning the response during the seat map request. We will also scale up Bookings service as it is stateless. We will add read replicas to Seat Db as read requests are multiple and final BOOKED seats will only be some 100k rows with only one way change usually. So for a given show writes will only be 100k for seats and can be easily handled by single node of Psql. For reads, we will just use read replicas to serve the traffic.

Now, we still have to compute left over seats from Redis and build that. We can reverse this and just send the reserved seats to users and make client side compute the left seats. So in essence, the user will get seat map for event as part of event details. While getting event seatmap, we can forward union of BOOKED seats in seat Db and locked seats from Redis as they are non-conflicting seats and even if repeats are present, doesn't harm the rendered seat map on user side.

Booking confirmation flow-Payment Failed

If the payment fails, then user should still be allowed to retry payment later. So we will have to introduce retry payment API which forwards to Booking service and then replays the original scenario after confirming lock is still held by the user.