> Michael Kelly # Designing a ticket reservation system REST API Collections /events { id:id, name:"name", time:"timestamp", venue: "reflink", capacity: < capacity of venue } /ticketRequests POST { event-id: ... buyer-id: ... quantity: ... creation-time: ... ttl: ... } -> will return an id GET { id: id ... } /ticketRequest/:id:/complete /tickets { id:id, event: "reflink to event", buyer: "reflink to user", } /venues { id:id, name: "name", location: { some sort of address}, capacity: capacity } /users { id:id, name:"name", identity: { some sort of reference to an external IdP}, address: { some sort of address}, } Tell me how you might design a system whose purpose is to reserve one or more available tickets for a given event name. Your system should allow callers to reserve a number of tickets for the event for 20 minutes while payment for the tickets is secured by another system. Assume for the purposes of this exercise: * Events are at venues all over the world * All tickets are of equal value (no "club seats", etc) * All callers are equal (no tiered or preferred ticketholders, etc) And here are some rough requirements for the system: * You will need to handle requests for 10,000 active events at any given time * The 10,000 active events will have between 1,000 and 100,000 tickets available for them * At any given time, you might need to handle 100,000 concurrent callers to your system * You should aim to minimize request latency for the system's globally-distributed users * You should aim to minimize the impact of a regional failure to users outside of that region Some questions to get you started: * What might a top-level API for your system look like? * What would a 1000-ft architecture of your system look like? * How might you store the data involved in your system? * What might the schema look like for the data involved in your system? * What parts of the data might need to be cached, if any? What might you use for caching? * How might you handle concurrent requests for the same event? For the same ticket blocks? * How might you handle errors returned by the payment processing service? * How might you think about the reliability and availability of your system? * How do you think about blast radius and handling failures across the various system components? * What kind of mechanisms might you put in place to evolve the system over time?