BOOKMYSHOW System Design, FANDANGO System Design | Software architecture for online ticket booking

hello everyone my name is Lorraine and in this session let's talk about system design for movie tickets booking platform like booked my show or Fandango designing a highly scalable system is pretty complex and it takes years to perfect also designs are continuously optimized and tweaked continuously over many years to get a highly scalable high available and fault tolerance system now without wasting much of our time let's jump right into system design for online ticket booking platform going forward I'm going to mention online ticket booking platform as BMS as a shortcut and B M stands for booked my show it is number one tickets movie tickets booking platform in India so any basic system or our tickets aggregate a platform looks something like this a user request a ticket through aggregator or BMS and the BMS intern place a request for seat or a ticket for a particular movie from the theater and how the system works let's talk a little bit about how this part of the world works with that in mind any third party ticket a litigator who supports booking tickets should work with this database in the theater side to get the information or place to get a booking now if you have booked a ticket on any of this platform you don't know that you can actually see the available and unavailable are already booked seats of a theater and how does this platform know what seats are available and watch what seats are not available so there two strategies again to know that information so the first one is connected theaters DB directly that means you can every system connects to the VB and raise the tables of the DB and use that information by caching to show to the customer which visits to us that way user can immediately know what sieves are available and what's not the second strategy is sort of connecting directly to the BB you can use the theatres API that means this server would have exposed some API like getting all the available seats in a theater and get all the unavailable seats in a theater and one more API to book a theater one more a v8 lock so when I say love why do we need a lock say there are obvious situations or scenarios that multiple users from different platform trying to book a same seat or acquire a same ticket that means we need a locking mechanism so who should handle that definitely these guys cannot do that if we go with the second strategy of anyone can book with book any tickets available in this DVD that means that this server should take care of locking a particular seat so if say for example if a user from DMS trying to book a seat number of one and if another customer from Paytm also trying to book the same seat and one more guy from Fandango also is trying to book a seat number one that means this server should take care of rocking the seat for the user who were come came first that means if the user from the BMS came first that means this seat will be reserved father for the user who came from BMS for about 10 minutes 10 minutes if user didn't book it within 10 minutes that means this seat will be marked available and then any other user from another platform of same platform can put the same ticket after 10 minute if you are using this strategy that is using theaters APA that means you will be making a lot of requests that is ibecause that is Network IO calls from your server to the theater server so that means you can you should be using pythons as if you want to do billion server using Python or if you want to use Erlang you can go with lightweight traits or if you want to use go you can go with go correcting these words a lot better when you are making a lot of network i/o or requests from your server now before designing the actual system design for PMS let's list out all the features which we want to support in the system as usual if you guys don't know the features or if you have any confusions around what we just to support and what not to talk to her in to where and get it clear and then you tell them that you're going to support these features and if he has any problem with that he's going to add what features he's expecting for it to you to support so now I want to enlist it down all the features which I'm going to support so now let's talk a bit about all these features ok so now the first feature is highly concurrent book my show in India of books about 90,000 or 95,000 tickets a day that means too many of tickets booking happening apart from tickets booking alone there are people who are reading comments ratings and then just coming here to see tickets availability and exit alright that means too many requests are happening that means we need to make our system highly concurrent the second one is responsive users are coming from different kind of devices like mobile phone applications you know tablets or desktop our UI should be able to make user experience better using responsive UI so third is this BMS not just supports one city it supports all the cities in India or any other countries like Africa New Zealand and etc so the same system should scale to support different countries and cities and it should also support digital payment like cars credit card debit card or wallets are bitcoins and etc so the fifth one is movie solutions so if user watches some kind of sci-fi movies then the next time our system should automatically suggest the user that another sci-fi movie has released and you might be interested in watching that movie so we need to support when we solution feature as well so this one is comments and ratings so people should be able to write comments about the movie they have watch and wait the movie also seven funny is moving for they should be able to see the crew cast pictures videos and trailers of the movie so we should have a profile for a movie so the eight one is we should be the system should send a Coughlin copy or a copy of tickets via SMS email or by whatsapp so with all these features let's draw the system design on the board and I'll explain every components individually and here we have the system design for book moisture now let's talk about each and every individual component this over here is mobile app or application and this is the desktop there can be two different place from where the users are visiting be book my show but the same application server serves the purpose okay so let's talk about lower balance obviously we need more balance to keep highly concurrent system when we are scaling the app servers horizontally so the load balancer have different techniques to balance the load that is you can use consistent hashing to figure out which app server the request should hit or you can go with round-robin where the requests are done Nick handle fashion or you can use weighted round robin or you can also go for least connection based strategy to do the load balancing and going forward this here is the front-end caching system called varnish it helps you lose the cache cannot only improve your UX but also help you to relieve the pressure on the overall back-end infrastructure over here also you can use CDN to cache your pages or api's or any video or image content and next is the app servers here you can see there are multiple app servers over here I mentioned it as app server so you need to scale these app servers horizontally to take the heineken to take the heavy load or to handle a lot of requests in parallel so specifically book my show users Java Spring swagger and hibernate in the App server but you can always go with Python based servers or you can also try node.js for that matter there is no specific answer that you should use this language or this particular framework it all depends on the requirements so the next is to support such api's for your to such movies or to such plays or shows what you can actually do is dump all the data into elasticsearch over here elastic search is really good and it is distributed it has just full search api is available in the system and it also can be used as analytics engine which which which which works on scales as a half level search engine to answer all the search queries from the front end so the next thing you can see is cache cache is very important to save all the information related to the movies some even though in the you know the seat ordering the place by theater are a lot of information you can actually use cash you can use memcached already's whereas the benefit of using Redis is it is distributed and persistent so going forward to the DB you can't just use one kind of DB that is a DBMS are no sequel it is always it always works good with the combination of our DBMS plus almost equal so what we can actually do is in case of this particular VMs or ticketing system we need acid property and relationship representation because the relationship will be something like you have a country's city and city has so many theaters and each theater can have multiple screens in it and each screen has multiple rows of seats and then a different tier of seeds and many number of seats right so there is a proper relationship and also there is a movie and to be attached to the same same relationship so we need a proper relationship to handle these tons of data right so and also we need to handle transactions so RDBMS is good since the data won't grow too much because the number of theaters and screens of the seats mostly remain constant upon addition of new theaters and new places only the data will increase so it's good to go with our DB means our DBMS like my sequel are four strips to save relational data and also we have tons of data like movie related information like from trailer actors through comments and reviews these are this cannot be saving our DBMS because this can be considered as big data or it's too much of data for our DBMS to digest so it can actually uses any kind of or sequel database where it is distributed by geo like Cassandra you can go with which is pretty good and good at holding this kind of big data like all the comments or the reviews all the ratings the throughs the actors and the movie information so I'm tonight I know it's about what we have to do is our DBMS also you need to have a Charlotte data by Geo and also you can go with either go with master master slave architecture where slaves can be used for reading as a read notes and master can be used for writes that way you can easily scale a hardy Venus as well so apart from that we need to have so now the benefits of using no sequel also is so since Nord distributed across geo and we can set the replication factor and tells you how many copy of the same data can be saved and also the consistency level that way you can always be sure that we won't lose the data and you know 99.99 percent of availability and durability also so for example if these two node goes down still we have the data in all the other three nodes going forward let's talk about the sync workers you can see over here so why do we need a sink workers so many times say say for example user has booked a ticket so we need to generate the PDF or we need to generate the PNG of an image or and also we need to send the emails and SMS or seven tickets via whatsapp so all these tasks are like making third party API calls say for example to send an SMS wait to make a call to video or to send a email we need to make a call to right these are like Network I whoa they add a lot of latency so in the same API request for ticket booking we can't execute all these tasks synchronously so what we need to do is as soon as the application server confirms the booking offer ticket then what they do is they add a message into the queue that ticket has been booked now you need to do the protein or work like sending the ticket via email SMS or sending the ticket via whatsapp and also you can do is send a GCM notifications saying that your six ticket has been booked successfully so all this time taking tasks our message will be added into the queue any workers which is free will pick up the tasks and they start executing the time taking tasks as synchronously so for this part you can use Python celery which we use heavily in a lot of distributed synchronous systems and also there are similar kind of distributed as synchronous workers available in Java go on etc so you can use any of that all works well so moving forward let's talk about business intelligence our recommendation engine which we spoke in the feech you know in the list of the features so to do that we need to obviously have a platform to get the business intelligence so what we do is all the lots all the user activities all the information can be dumped into Hadoop HDFS as a law dump of log file or something then on top of it we can run big or high queries to extract the information like like user behavior or use a graph or so if you can plane our machine learning model using the same data to free to do recommend movies for the customers are the users so in in the meanwhile we can use say something like Kafka in between Kafka queue in between tough got you in between and tweet the data into spark to do something like real-time analysis we can either use spark or storm over here to get the trends or latest trends or what's happening in the system and also to understand the user activity and behavior and also sometimes we can do figure out fraud detection and mitigation strategy using this park and storm stream processing engine so that way as yeah that that's about it so moving forward what we can do is here you can say you can see that there is a payment gateway this we can go with a third-party payment gateway like for example just BMS users just pay which has a lot of different vendors credit cards banking application banking banks and all the different wallets so we can just so when the when there is a ticket request to book a seat so we can rewrite to the payment gateway and once the payment is confirmed we can issue the tickets using a synchronous worker and a copy of tickets in the synchronous API called also now let's talk about the working steps what happens when a customer comes to BMS and books a ticket so the first step what he is going to do is customer comes into he uses the application he does the location filter and sorting and going into the movies to the specific movie so to find the location what we can do is if it is a mobile phone we can use the GPS location available to the mobile phone or if it is a laptop we can use the ISP Internet service provider there's IP based location strategy to figure out the location of the user and we can set all the nearby theaters and the movies which is released in that particular area so then that when the user selects a movie he checks the different timings available in that theater and the next thing what he does is opens particular timings for for theater and then he sees all the available and unavailable are booked tickets for seats now what VMs should do is should also lock the seat for the next ten minutes what it does is VMs system makes a call to the theater which which I showed you in the very beginning of the video it makes a call to the theater DB to block the seats so now the ticket is booked temporarily to our user trying to book so every other app in the theater or other system or the other aggregator can't book the same ticket now the user can proceed to booked the ticket are the ticket or the seat will be reopened if he didn't book it after 10 or 15 minutes now what it does is if the user continues to work he will check the invoice with a payment option using the payment gateway over here and then the request will be processed and then a callback will be happen to the app server saying the payment is processed and successful so once the payment is successful the theater who gives you a unique ID and that will be received in the app server so what what BMS does is using that unique ID a ticket will be generated you are code which is attached to the gate and a copy of ticket will be immediately shown to the user and also a message to the queue will be added to send the same copy of tickets with the information like date/time play is a QR code and the address of the theatre and everything will be sent via email SMS all the tickets so now what happens is when a customer goes to the theatre he shows the QR code and the same ID will be also saved with the theater so then both match the ticket ID and then the user enters the theatre so yeah that's the overflow of how user interacts with the system BMS is built entirely on Amazon platform it uses micro service architecture like every component is separated out and they run independent of they are not monolithic architecture so all these app servers are and the workers are hosted on ec2 instances of Amazon and the sealian is cloud fair and more all the trailers gallery are saved in s3 of its own but my shows UI is built on top of react.js bootstrap J's and CSS the server they use is Chavez spring boot swagger and hibernate so the database which they use is my sequel and the server or I haven't shown here is used Tomcat for the caching they have used hazel cast for all kind of distributed system there they are using traffic and cue over here and the payment gateway they are using just pay for the deployment of the whole different micro services they use docker and ansible and along with that they get for to maintain the core base for logging collection and monitoring what the do is all the logs are pushed to log stash and locks - can read from syslog lock file or queue and everything all the logs will be sent to log stash and locks - based on a lot of filtering conditions will be redirected to l stack or does a lot of different actions like it can send a notification yr HipChat whatsapp or it can even raise Jitterbug based on filter the logs will be redirected to ELQ in here on cabana we can build a dashboard to see how what is the error rate and etc so hard from that the lower balance which they use is nginx and that's it let's see what are the tables which we need it for the system design which we just saw so obviously we need a table with place the same table can be used to save the hierarchical data for any given theatres like country state City and the street where the the theater is so that we want to many relationship and every theater will have multiple screens in it so we need to have one to meditation ship between theater screen and each screen will also have different tiers of seats or different kind rows of seats opening multiple deer and then every tear will have different seats so the pricing for different tier of seats varies so this is where we can handle that so each tier will have multiple seats so also only one movie can be played in a particular screen at any given part of the time so there will be only one to one relationship between screen and a movie we also need our first stage our first table that contains all the different offers available for a particular movie or it can be for a particular screen or it can be a for a particular seats and also we here we need to have a user table which contains user information and if one user can book multiple tickets and each ticket can have multiple seats in it so this is the high level database table structure here are the list of tables which we need in no sequel database the tables depends on the queries in no sequel we need to anticipate all the different queries and we have to do the data modelling based on the number of queries which we are going to support in the system so and also you can see that there are no relationship between the tables as in no sequel we can't have we can to join and we can't meet in the relationship and here are the high level did tables which we need to have in no sequel like we need a table to save all the comments for a given movie and we need a table to save all the ratings for a given movie and also we need a table to save information about the movie like description and synopsis etc and we need a table to save all the video and audio information or the path to the images and the videos of a given movie and we need a table to save artists related information and we need a table to save cast and crew and we need a table to save all the reviews about the movie and we need a lot of many different tables to save analytics data which will be consumed by the back-end team system design is not simple system design is subjective it depends on the requirements features it depends on the location kind of user base and etc so there is no such thing as ideal system design for a particular system system design evolves by time and it gets optimized and tweaked so if you guys like this video a power system design for book my show or ticket booking platform please do subscribe to my channel and leave a comment and share this video with your friends thanks a lot

Channel: Tech Dummies Narendra L

Views: 160,110

Rating: 4.8181272 out of 5

Keywords: Amazon interview question, interview questions, interview preparations, algo and ds interview question, software interview preparation, developer interview questions, Facebook interview question, google interview question, Technical interview question, simple algorithms, easy learn algorithms, system design bookmyshow, system desing fandango, system design onine movie ticket booking, system desgin paytm movies, system desing inerview question

Id: lBAwJgoO3Ek

Length: 27min 17sec (1637 seconds)

Published: Sat Aug 04 2018