System requirements
Functional:
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
event listings
read
seller post
seat selection
payment
ticket management
Non-Functional:
List non-functional requirements for the system...
high availability for users who need to access tickets
scalability
reliability - failures could result in failed transaction or worse data loss
strong consistency - we need to ensure tickets are sold and held by one person and one person only
Capacity estimation
Estimate the scale of the system you are going to design...
checkouts we could assume to have largest QPS as in ticketmaster case i'm assuming 10k rqsts/sec
SPACE estimation we will need to store user data, ticket data, venue data but all this is mostly metadata that won't be huge
let's say upper bound of 100M users at 1 KB each 100GB of user data
let's say 10k venues with 1MB of data relating to seating and other properties
10k * 1MB = 10GB
API design
Define what APIs are expected from the system...
/create_listing
/read_listings?filters=
/select_seats?listing_id=
/buy_ticket?ticket_id=
/access_ticket?ticket_id=
Database design
Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...
some entities we want in the system
ticket, listing, venue, user, seller, payment info
ticket table
ticket_id int
seat_id int
listing_id int
venue_id int
owner uuid
payment_method int
listing table
listing_id int
venue_id int
event_metadata string
user table
user_id uuid
profile info
seat_table
seat_id int
venue_id int
venue table
venue_id int
seat_map blob
payment table
payment_method int
payment_data int
seller
...
High-level design
You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...
listing path
client creates a listing by choosing a venue and providing some info abt the event in payload
api forwards to service which creates tickets, propogates new data to data stores and indexes the listing appropriately (let's say simple DB for now)
a moviegoer can search the db by sending some filters in "read_listings" request to construct a SQL query which will query SQL db with listing info
next a user selects a listing they want to go to and this issues /select_seats which loads seat map info (which may include special data structure so is in a diff database) and venue info / available tickets
when the user selects a seat this will contact the seat service to reserve the ticket in the db by marking it's owner temporarily
a user must finish the transaction by issuing a payment which will first make sure the ticket is held by the same user, then issue a request to the payment gateway, if the payment fails it contacts the ticket service to unmark the user from the table
after transaction
client can do certain operations using ticket management service, but namely we persist the ticket in some highly available low latency storage (Redis?) so that it can be accessed (when owned) quicker than a regular DB call
Request flows
Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...
Detailed component design
Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...
ticket_service
this piece is critical for ticketing function. we need to make sure that we don't charge to people and we don't give the ticket to two people
to make sure we have strong consistency we use an ACID database like MySQL to ensure even as we scale we can't have race conditions on writes
caching layers -
we would implement caching layers between all database accesses where applicable
however for the transaction handler we cannot use a cache unless we are guaranteed the same consistency as the underlying DB. some considerations would need to be made for consistent cache
load balancing -
would be critical to scaling the ticket service in peak qps when ppl are buying tickets
rate limiting - prevent bots from DOSing or snatching up all the tickets. ip based limits to ticket api
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
you could charge parties and refund later based on who the ticket actually went to but this is a very bad experience
we require strong consistency so we sacrifice on availability CAP theorem
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?
index listing data for easy search
smarter cart/ checkout system