System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

Look up event and event dates

Dynamic Ticket pricing based on time/#of tickets and location of seat or ticket level

Purchase ticket(s)

View purchased tickets

Refund ticket

ticket packages/deals

Non-Functional:

List non-functional requirements for the system...

Transactions should be consistent and not fall off midway through

Minor latency is allowed in ticket purchase but confirmation needs to be sent back quick that the user has made the purchase action

request processing for the type of ticket needs to be handled in a stable way when two users are purchasing the same last ticket

servers need to available at all times in case customers need to check their portal to purchase or refund a ticket

servers need to be fault tolerant to ensure ticket processing can be completed in a proper manner

We need to be able to scale for an increasing number of users that come in

We need to ensure very tight security so our clients payment and account data is properly shielded. Could be through a third party verification service

Capacity estimation

Estimate the scale of the system you are going to design...

We can make an assumption that there are about a 100 million users using ticket master at a time

A user will generally only look up a singular event at a time but the higher echelon of users may look up more maybe at a high of 10 different events

thus number of search queries can be an average of around 4 a day per person which would be close to 400 million per day.

Converting this to queries per second would be around 400 million/24/60/60 which is roughly rounding up to 5000 qps

A user may need to review a multitude of prices available for a ticket so that may require querying for more. Per event we can probably average 10 lookups for different seats. which would essentially be 50000 qps instead.

for actual ticket transactions 5000 qps would be the roughly correct as well.

API design

Define what APIs are expected from the system...

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

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?