System requirements

Functional:

• Customer can buy ticket
• Customer can view an event
• Customer can search for events

Non-Functional:

• Consistency in the buy process
• Low latency Search
• High Availability for search, eventual consistency accepted

I will not cover the following topics ass out of scope

• Monitoring
• Data private and security

Capacity estimation

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

API design

All end points use jwt token for user auth

Search for tickets

GET api/search?terms={}

Get event

GET api/event/eventID

Reserve ticket

POST api/ticket/reserve

Buy ticket

POST api/ticket/confirm

Database design

Event

• id
• location
• name
• date

User

• id
• name
• password
• email

Ticket

• id
• event_id
• price
• purchased
• payment_id

High-level design

Request flows

when a user makes a request, the user/customer searches for an event. This request got to the event service which goes through a full-text search engine like Elastic search. The result here is a list of events that relate to the search term.

The user then selects the event id in the result set for the event they are interested in.

Once this event is selected, you have the option to reserve the ticket, once reserving, a lock is generated on the ticket. This means its now excluded from the search result set when searching for results in the initial search flow.

You will be given a certain amount of time to purchase this ticket. If you do not purchase it in the allocated time, the lock will be released and it will be visible in the search results. Once the decision is made to purchase the ticket, it will be confirmed by the purchase service which will go through the payment service to make the purchase.

Once the purchase is complete, the ticket will be marked off as purchased and no longer visible.

For a popular show like Taylor Swift, to prevent the the service from being over loaded with a thundering herd, a queue can be put in place where the customer is notified that they are in a queue and have to wait for the Event service to mange the reservation process.

Detailed component design

Ticket Search:

Here we are using full text search because it can handle high reads. Elastic search is highly available and is partition tolerant. Works well even if some nodes go down> it however provides eventual consistency by default which will not be a problem as events are not frequently added.

Redis for Distributed Lock:

Redis is a very popular option for distributed locks. It has very fast reads and writes as it is in memory. So a Redis cluster can store a ticket id for the purpose of reserving in a fast time and have a TTL for when to release the lock and make it viewable again

Trade offs/Tech choices

Full Text Search:

• If tuned for High Availablity, the consistency will be low. Thgis will not have such a bad impact on system as events are not always added
• In the event a popular artist like Taylor swift has an event, the service will experience degraded performance due to high reads. Query Caching and adding replicas could mitigate this. But his will come at the expense of some memory and the cost of replicas

Redis:

• Redis is an in memory store so it is expensei

Failure scenarios/bottlenecks

• The RDMS can be a bottleneck in the event of a popular event leading to massive writes.
• In the event there is a major failure with the Redis clusters, there will be a small window where the locking mechanism fails. This will degrade the user experience but because the RDBMS is ACID, the purchase process will still be consistent

Future improvements

• To deal with the RDBMS bottle neck, we can come up with a sharding strategy to spread the writes in a master replica strategy. In the event of a masters failure, a replica is promoted to handle writes