System requirements

Functional:

* EventManagers can create new events, determine sale prices, sell etc.

• Customers can purchase tickets
• Real time pessimistic locking system to prevent over purchasing and still preserve customer experience
• Multi channel communication ahead of event
• Artists are able to send communication
• Advertisers can buy data
• Functionality to filter out bots

Non-Functional:

* Strongly consistent

* Fast - there should be no latency

* Explicit - all statuses should be very explicit

* Ability to handle huge bursts of traffic

Capacity estimation

* 100000 within a minute, or even a couple seconds

* Ability to model stadius with 200,000 chairs

API design

Let's focus on just the buying of tickets for now.

* getEventStatus() -> EventStatus

• acquireLock() -> LockStatus
• purchaseTicket(Seat, Payment)

Database design

* Database will be 2 tables, 1 will have Reservations and 1 will be Events

* Events will have the following columns: [event_id, event_name, event_description]

* Reservations will have the following columns: [event_id, user_id, venue_id, seat_id, lock_expiry, session_id, reservation_version]

* ReservationHistory will be an event sourced log of transactions and Reservations will be the view on it

* Venues will have the following columns: [venue_id, seat_id, seat_location, seat_type]

High-level design

* We will have a system where we have a series of tables that enable modeling the reservation and event status. We will use stream processing to enable driving real time counts in our distributed system.

Request flows

* User logs in and wants to see how many seats are available, we can use flink/data analytics to quickly tell how many seats are available. From there, they try to enter a reservation workflow, they aquire the lock and then if they complete it, it is reserved. On the backend, each load will require querying the ReservationsTable and Venues table and joining the result to determine which seats are available. To make this quicker we can use an elasticsearch index.

Detailed component design

* Server will provide APIs that enable interacting with the database. It will construct the queries and writes using conditional expressions and optimistic locking.

Trade offs/Tech choices

* Pessimistic vs optimistic locking for selecting seats and entering payment workflow

* Optimistic or pessimistic fulfillment for telling users whether payment succeeded

* Whether we build a fix it workflow when payment fails

* How much fraud and bot analysis to build

* How long locks should live for

* How many seats someone should be able to reserve, what the bulk buying experience is

* Whether to make the available seats count strongly consistint (and thus require transactional locking on purchase which could increase contention) or to make it eventually consistent and thus dissapoint users who see that there are seats available but are unable to enter the workflow to purchase a seat. You can use something like Apache Flink or AWS Kinesis Data Analytics to enable real time stream processing and keep the available count up to date.

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

Future improvements

* Analytics on ticket sales