Design Ticketmaster - System Design

System requirements

Functional:

As a user, I want to view events relevant to my demographic (personality, location, cost, venue, accessibility) including availability of tickets, cost, time, and transportation
As a user, I want to purchase tickets for relevant events using common payment platforms such as credit card and gift card
As a user, I want to check the status of any tickets purchased or "watched" so that I can cancel/modify if needed, as well as keep up with any cancellations due to inclement weather or unforeseen circumstances
As a user, I want to use a platform that is fair and not subject to ticket resellers ("scalpers") in a cat-and-mouse game where I have to constantly monitor the ticket page
As a user, I want to gift tickets to family members and friends, as well as purchase tickets for groups
As a user, I want to feel safe knowing that my purchase(s) can be verified later at the venue/amenity(ies), as well as send said purchases to others (especially in a group purchase environment)

Non-Functional:

Database should place particular emphasis on consistency of data; while online services are more forgiving to race conditions, physical constraints such as the number of available seats cannot be negotiated (especially given fire concerns); as such, it should be impossible (or nearly impossible) for transactions to duplicate or reach an illegal state
Particular emphasis should be placed on the visual, textual, and data feedback given to the user, as in today's culture, ticket scalpers have driven a wedge between customers and providers (such as TicketMaster). This means a transparent process allowing users to see exactly when they're guaranteed a "spot", their purchase, as well as relevant proof tokens (purchase id, for example)

Capacity estimation

Such a system would require a lot of R&D; in fact, I reckon the R&D would outscale the actual development by several magnitudes.

Some things to note are the market demand for such a service; given recent controversies with TicketMaster, analysts would need to look for holes/gaps to potentially fill from TicketMaster (region, features, constraints).

Assuming this market research is done, the following other steps would occur:

Vetting financial entitlements with higher-ups to justify the project (several weeks to months); this would recursively involve talking to other teams and PMs/finance managers to get the numbers, as well as the "cost of not doing it"/impact
High-level design document (involving a principal engineer, or SDEIII), as well as several meetings to review with team(s) + stakeholders (1-3 months). This would involve rough services/numbers
Low-level design document (1-2 months) that capitalizes on what was agreed upon with the high-level document; in particular, it'd talk about specific services/api names; meetings with teams and sign-off
Grooming and sprint/task/epic allocation (2 weeks) -- using the low-level design from earlier, this would break the project up into sprints/tasks, as well as groom them, marking dependencies/blockers, and likely loop in managers/TPMs
Setting up the skeleton services (2-3 weeks) -- barebones microservice API connected to a database with test data
Setting up the CI (1-2 weeks)
Fulfilling user stories (3-4 months)
Rollout and e2e testing (1-2 months)

Roughly this would take 13-15 months in my eyes.

API design

The service would be web-oriented through HTTP requests and likely some rpc protocol for complex object mapping. The `...`ellipsis signifies tentative/unknown parameters

authenticate(...) - this would create a unique session token for a given user, needed for later APIs
getEvents(...) - this would the API that returns nearby events, taking in some combination of the authentication token from earlier as well as a query object (likely a JSON) representing the search parameters. As this business logic would change over time, we prefer using an object rather than a static number of arguments. If speed and schema are prioritized, perhaps protobufs can be used to make sure exact arguments are not "out of date". The resulting object would likely be of the same shape (e.g., some rpc object, json, or protobuf) in order to also help forward/backward compatibility
makePurchase(...) this would likely be business-logic only, and proxy outward to an external vendor like Stripe or Plaid, as we don't want to handle payment info raw
getPurchase(...) this would be to return an existing order
updatePurchase(...) this would be an update operation (potentially to cancel or reschedule)

Database design

User schema would have personal info as well as a unique ID
That being said, there exists a 1 to many relationship with "events" and "people who purchased tickets for said event", so SQL is out of the question
I would prefer DynamoDB, which is less rigid than SQL, allows lists, and is reliable
Each user would store a list of event IDs (or whatever primary key is used for an event), and each event would store a list of user IDs (or whatever primary key is used for the users purchasing)
Users would have a unique key, as would events, but DynamoDB allows GSIs, so the sort key on users would be name and birthday, concatenated. The sort key on events would be date, in iso8601 format.

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...

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...

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?