Requirements
Functional Requirements:
- Users can see available shows.
- Users can view a seating map to pick seats.
- Users can purchase a seat from their selected show
Non-Functional Requirements:
- Consistent for purchasing - You can not allow the user to buy seats that are not available or already reserved
- High availability - You must be able to show users the seats and shows they want to see so that they can look into reserving (funneling)
- Shows can have huge spikes of traffic, so 100k+ users might be looking at one show at a single point in time
API Design
Objects
Users {
id
}
Shows {
id
show_start_time
ticket_release_time
title
artist
location
description
}
Seats {
id
show_id
reserved_by_user_id
bought_by_user_id
}
GET /shows
Paginatied, request by offset/limit
Returns list of shows
Can be sortable
GET /
Authenticated to only allow user seeing their own ticket (maybe admins in the future can do more)
GET /
Get seats available by show ID, eventually we can serve this information realtime like ticketmaster and have a queue, but lets make it simple for now
POST /
Try to reserve a seat before buying
Returns JSON Object body, true/false saying you can now purchase the seat you reserve for X expiration time
POST /
Hand over the purchase information (we can use payment handlers like stripe for example, but ultimately the request after filled will be send to this placement)
Can return invalid due to reservation expiring
POST /create_show
Will create a show that will launch at a specific time that the user mentions
High-Level Design
We will want to have a ACID-consistent database so we do not accidentally give 2 users the same ticket and accept their payment. In order to do this, we shall use a relational database postgresDB (I use this more often, but we can look at more specific edge cases that use other relation database types as we need). From here the user will be coming in from mobile and web devices into a load balanced API based on geo location, which for purchases, gets MQ'd down to the postgresDB which then consumes and confirms the purchase.
To handle GET requests, dude to the high volumes of user, we'd probably want to cache information like shows available, seats, in memory like REDIS so they can be instantly available without hammering our database.
Detailed Component Design
Pre-computing information will be required to set up the database for success once showtime hits. Basically what we need to focus on is user creates show -> worker builds seats required in database -> send show and seats to cache -> wait for release before accepting reservations.
Redis can be used to cache the shows and seats available for fast lookup on reserved, and also just fast delivery.
MQ's will be used just for purchasing to