Loading...
* EventManagers can create new events, determine sale prices, sell etc.
* Strongly consistent
* Fast - there should be no latency
* Explicit - all statuses should be very explicit
* Ability to handle huge bursts of traffic
* 100000 within a minute, or even a couple seconds
* Ability to model stadius with 200,000 chairs
Let's focus on just the buying of tickets for now.
* getEventStatus() -> EventStatus
* 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]
* 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.
* 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.
* Server will provide APIs that enable interacting with the database. It will construct the queries and writes using conditional expressions and optimistic locking.
* 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.
Try to discuss as many failure scenarios/bottlenecks as possible.
* Analytics on ticket sales