System requirements
Functional:
List functional requirements for the system (Ask the chat bot for hints if stuck.)...
1) User Registration and Authentication:Users should be able to register an account using their email or social media login.
2) Search and Browse Movies:Users should be able to search for theaters by city or ZIP code
3) Show Timing and Availability:After selecting a movie, users should see available showtimes for that movie
4) Seat Selection:Users should be presented with a list of available seats for their selected show.
5) Booking Process:Users should be able to finalize their booking, which includes confirming the selected seats.
6) Payment Processing:Users should be able to pay for tickets through multiple payment methods (e.g., credit card, PayPal).
7) Booking Management:Users should be able to view their booking history and manage existing booking
8) Notifications:The system should notify users of key events like booking confirmations, cancellations, or upcoming show reminders.
Non-Functional:
List non-functional requirements for the system...
1) System should be highly available
2) System should be fault tolorent
3) System should not produce any inconsistent result (Two persons booking the same seat)
Capacity estimation
Estimate the scale of the system you are going to design...
Lets assume 100,000 DAU and let 500,000 be MAU.Lets assume at peak time we have 300,000 users lets assume each application server can handle 500 requests then the number of servers required 300,000/500 =3000/5= 60 servers
API design
Define what APIs are expected from the system...
As there is no service to service communication so we don't need to use rpc and as we don't need graphql as we are not getting data from multiple data sources so as we are only focusing on crud operations so rest api will be optimal
POST /v1.0/registrer- Allows users to register to the ticket booking site
Host example.com
{
userName:"",
userId:"",
phoneNo:""
}
GET /v1.0/Search/?MoiveName&genre=& allows useres to search movive by name, genre
Host exmaple.com
Get /v1.0/timing/?movieName=& List the shows and their times
Host exmaple.com
GET /v1.0/seat?movieName=&showTime= show the seats which are currently available
Host example.com
POST /v1.0/book Allows user to book a seat
Host example.com
{
movieName:""
show:""
seat:""
}
Get /v1.0/bookingDetails?UserName= Get the seates booked by the user
Host exmaple.com
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...
As discussed with the interviewer we want more consisitent results rather than availabitlity so we will be using a relation database as relational database guarantess strong acid properties using transactions and we will be using serializable isolation level that will lock the rows and then perform the operations which will not allow any locked row to be used used by another transaction. In order to speed up the process instead of aquiring the lock on the rows we can store the seat in cache like redis
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...
For registration each user will make a request to register api which will alow the users to authenicate using eamil id password or through oaut2 authentication after sucessfull authentication the user call will be made to movie service which will list the movies and the available shows the user can select the show the and seat . To prevent double booking we can use pesemitic loooking or optimistic looking in pesimitic looking the seat is locked until the user has booked the seat and this will not allow any other user to book that seat this approach is not that efficient as a user can never book a seat and keep switching between the booking page and seat page other approach can be using optimistic locking in optimistic locking we will check whether available flag is set at the time of booking the seat if it is present then we will book the seat else the seat will not be booked .
We can also use cache like redis to store the seat number which is booked and before booking other seat it will check if the seat is not present in the cache then only it will book the seat otherwise it will not book the seat. Although sql databases are not meant for horizontal scalling we can scale the database by following master slave replication where master accepts the reads and read replicas servers all the read. Also there can be few scenarios where the movie or show is being booked by more number of customers than other shows for this scaniors we can shard the movie by movie-show or by movie-time to guarantess less load on particaular shard and high scalability.
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...
For registration each user will make a request to register api which will alow the users to authenicate using eamil id password or through oaut2 authentication after sucessfull authentication the user call will be made to movie service which will list the movies and the available shows the user can select the show the and seat . To prevent double booking we can use pesemitic loooking or optimistic looking in pesimitic looking the seat is locked until the user has booked the seat and this will not allow any other user to book that seat this approach is not that efficient as a user can never book a seat and keep switching between the booking page and seat page other approach can be using optimistic locking in optimistic locking we will check whether available flag is set at the time of booking the seat if it is present then we will book the seat else the seat will not be booked .
We can also use cache like redis to store the seat number which is booked and before booking other seat it will check if the seat is not present in the cache then only it will book the seat otherwise it will not book the seat. Although sql databases are not meant for horizontal scalling we can scale the database by following master slave replication where master accepts the reads and read replicas servers all the read. Also there can be few scenarios where the movie or show is being booked by more number of customers than other shows for this scaniors we can shard the movie by movie-show or by movie-time to guarantess less load on particaular shard and high scalability.
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...
For registration each user will make a request to register api which will alow the users to authenicate using eamil id password or through oaut2 authentication after sucessfull authentication the user call will be made to movie service which will list the movies and the available shows the user can select the show the and seat . To prevent double booking we can use pesemitic loooking or optimistic looking in pesimitic looking the seat is locked until the user has booked the seat and this will not allow any other user to book that seat this approach is not that efficient as a user can never book a seat and keep switching between the booking page and seat page other approach can be using optimistic locking in optimistic locking we will check whether available flag is set at the time of booking the seat if it is present then we will book the seat else the seat will not be booked .
We can also use cache like redis to store the seat number which is booked and before booking other seat it will check if the seat is not present in the cache then only it will book the seat otherwise it will not book the seat. Although sql databases are not meant for horizontal scalling we can scale the database by following master slave replication where master accepts the reads and read replicas servers all the read. Also there can be few scenarios where the movie or show is being booked by more number of customers than other shows for this scaniors we can shard the movie by movie-show or by movie-time to guarantess less load on particaular shard and high scalability.
Trade offs/Tech choices
Explain any trade offs you have made and why you made certain tech choices...
1) Sql database gurantess consistency but does not provide strong availableity
Failure scenarios/bottlenecks
Try to discuss as many failure scenarios/bottlenecks as possible.
As we have a single master in sql database so master failure can be possible in which one of the read replica needs to be promoted to master
Future improvements
What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?
1) Adding machine learning algorithms to improve user search