Loading...
Assume 10 million accounts
Assume 100 million purchases per month
Assume a ticket size is roughly 50 bytes (user_id, purchase_time, show_id, price, seat)
5 billion bytes of purchase data per month.
60 billion bytes a year
account API - will be connected to an authentication service and will manage the process of opening a new account and logging into an existing one.
Transaction API - will be connected to a purchase service and will manage the booking of tickets.
Read API - allows a user to browse the movies, their locations, their trailers, and showtimes.
I choose to use a relational DB since we have a lot of data and little room for flexibility. The data needs to be highly structured and we do not need to allow for duplicates. we also want to support complicated joins
Tables:
Users: userid, username, password, email, previous_purchases, upcoming_event, payment_info, birth_date
Movies: movie_id, release_date, trailer, length
Theaters: t_id, location, presenting_movies
presenting_movies: movie_id, theater, times
The client through the web server can create an account and also access an existing account.
The client through the web server can purchase a movie to a ticket which will be posted to his account.
The client through the web server can browse the upcoming movies and their times.
The Accounts API has an authentication service and is also connected to the DB.
The transactions API has a payment service and is also connected to the DB.
The read API is connected to the DB.
there DB has some master-slave replicas that help with scaling. It also has a cache and an object storage. There is a CDN connected to the object storage.
browsing for movies:
The user will be redirected to the read API, which will query the DB and present the available movies. The API will allow filtering based on movie, location, time. The object storage will be used for example to store movie trailers.
Purchasing a ticket:
The user will be redirected to the transaction API which will query the DB and using the payment service will charge the user. The tracker service will update the capacity left at the theater and the seats available.
opening/logging into an account:
the user will be redirected to the accounts API and the authentication service will assist the user. New accounts will be stored in the DB.
read API: connected to the database and allows filtering based on movie name, time, theater etc. Queries the DB and presents the relevant information. To fetch static content like trailers, the CDN and the object storage will be called.
tracker service: keeps track of the available seats left in a theater. It keeps a dictionary of theaters for every location. each theater is a dictionary as well with the seats as key as a boolean "status" as values to indicate if they are taken or not.
To support the DB we have master-slave replicas that will serve all the read requests and also a cache that can save the most popular movies at the moment to reduce access to the DB.
chose a RDB instead of a NoSQL.
Bottlenecks are possible at the DB. We have master-slave replicas which means that the slaves can only serve the read requests. If many purchases happen at once, the master DB will be overloaded.
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?