Great video, wanted to correct a wide-spread incorrect assumption about Relations in context of RDBMS. A "Relation" in RDBMS do not represent the relationship between 2 tables. Many believes thats the case. But Relation in RDBMS means a "Table". So all rows belonging to a Table is "related" set. In other words Table=Relation and it stems from the Set Theory.
@aneeinaec3 жыл бұрын
Isn't it related to entity relation ship model? Which is relation ship between entities and entities represented by individual table?
@Imkflow3 жыл бұрын
@@aneeinaec relationship*** != relation
@TZ-oi4od Жыл бұрын
This is a good example of how an SDE i/ii would design the BMS in an interview, as interviews would like the candidate to talk more about how the 15 mins locking period (book to pay) is implemented and how the tickets are not oversold when the QPS is super high. Narendra I'm wondering how would you do if you are asked to record this video again after 5 years, thanks!
@shivaprasad.v.g75264 жыл бұрын
Compared to other videos this lacks technical depth. How exactly locking happens , how theater API's works , why do we need logstash etc are required in my opinion
@suryatej37912 жыл бұрын
Locking probably at database isolation level via read committed technique
@satishpatel35182 жыл бұрын
locking is database concept with verious lavel ex. write lok,read lock,both ....
@RaviChandraEnaganti3 жыл бұрын
In the architecture, the ELK stack is generally to be used for server log aggregation and searching. For Searching, You might just need any indexing database like Lucene based Solr, Elastic. The data can be indexed to the search databases from the transactional systems using a pipeline.
@vishnuv4813 Жыл бұрын
Does ELK forms Elastic search,Logstash and Kibana? Why again separate specification of Lucene or its derivatives? Pls clarify
@RaviChandraEnaganti Жыл бұрын
@@vishnuv4813 Yes both of them can be Elastic search. But it is better to maintain separate instances of Elastic search for logging and Application search for the sake of separation of concerns. Logging might be huge data, application search might have relatively less data. If you have the same search database for both, you might face noisy neighbor problem i.e log data causing slowness in the response of the application. Micro services architecture prefer separate databases for separate services.
@ChinmaySrinath5 жыл бұрын
This is a sure fire way to flunk a system design interview. System design interviewers generally look for the application specific design details rather than bunch of product/technology propositions. Buzzwords without substantiation raise an immediate red flag.
@pkr6195 жыл бұрын
What buzzwords did the presenter use exactly? Is it a database, cache, server, load-balancer or locking? The video covers a 10k feet view of a system. it doesn't need to be very specific. It's abstracted but solves the problem.
@aditandadit5 жыл бұрын
Completely Agree, This may be covered in the first 10 minutes as a High-level Application design. But Any actual interview would involve Data model (Entities + Relationships), API, Concurrency and so much more. This video taught me absolutely nothing I didn't know from working as an engineer in the first place
@pandiarajanrajendran45056 жыл бұрын
This is one of the high quality system design content. Very useful. Thanks a lot. As others mentioned, I'm also expecting LLD from you. As these days a lot class designs are expected during interviews, like designing a HTML parser, parking lot, ORM framework, DI container, unit testing framework.
@diptidesai73995 жыл бұрын
Absolutely Superb explaination in just 27 mins...i cleared most of doubts and gave knowledge on the latest techologies like NoSQL. Thank you, Narendra. Great job. May God bless u
@sunny0287 Жыл бұрын
Great content ... very well explained in simple terms and at perfect pace.....
@yusufmirkar6508 Жыл бұрын
03:50 did not understood how locking will solve the issue . if two update queries running at same time will book the seat is the issue, then even two lock requests/queries at same time will lock for both users. this is more of a database internals than having a lock api separately
@ameerm78943 жыл бұрын
Great explanation of each comments, usage and use cases etc... Keep it excellence work...
@vivekgrewal81294 жыл бұрын
I watched your other system design videos which are great. But I feel this one could be better if you would have focused more on the microservices which we will have in this use case and how they are interacting to fulfill our requirements. And less focus on specific technologies. The system design diagram looked more generic which should highlight more on solving the business problem.
@Whatevername742 жыл бұрын
i agree with Vivek here. This is a very generic design. you should put in the service names naming which one handles what responsibility . You also have mentioned nosql and cache. would have been better if you started simple and then address how adding these 2 will address the problems related to speed and concurrency.Try #CodeKarle channel's system design for air bnb its quite similar question about tkt booking and he has explained it much more better.
@connect2rajib5 жыл бұрын
You are really good in teaching.Please keep up the good work.It is helping millions of people like us to learn.
@orpat0076 жыл бұрын
you are my new favourite on youtube. Keep up the good work. Thanks for such informative videos.
@cseshivaprasad19853 жыл бұрын
I have been lately following your system design videos which have good meat in it. Specifically for this video, I feel it could have been made better focusing on the crucial information - Strong Consistency handling with Optimistic Concurrency Locks, how it fits into this use-case - Good reasoning around the choice of DBs for Search and Booking and how does the data synchronization happen between the two - Pub-Sub model when we publish single booking event and how it will be interpreted by its subscribers for its own use-case such as notification, analytics etc.. - Reasoning covering the choice of the DBs such as CAP theorem fitment, scale, schema flexibility, data distribution - Clear separation of Functional and Non Functional requirements
@codedestiny69553 жыл бұрын
Yes specially booking the same seat by users, suppose your system is getting 100k request per day How you're going solve this problem ???
@yogini13512 жыл бұрын
Great question. @TechDummiesNarendraL Would like to hear your solution to this problem
@dharmendrabhojwani6 жыл бұрын
Nice video. Initially I thought he can't do it but I was wrong. It went very well. Nice. Looking forward for more such videos
@TechDummiesNarendraL6 жыл бұрын
Dharmendra Bhojwani Thanks a lot, am pretty new to explaining stuff and I am always open for suggestions. Please do suggest me some improvements.
@krishnaverma77445 жыл бұрын
I can see you worked hard for this video Very clear and easy to understand Thanks for sharing
@sureshbabu-ne2kv2 жыл бұрын
Impressed, It has huge information bro
@anastasianaumko923 Жыл бұрын
Thank you so much for your work 😌 Very educative
@sajaljain3610 Жыл бұрын
Superb Video and Explanation, thanks for continued help.
@PARVEENKUMAR-qr9cz Жыл бұрын
Nice informative video from beginner perspective.
@lordlynxtube6 жыл бұрын
Your system design videos are very good. Please do more.
@TechDummiesNarendraL6 жыл бұрын
Thanks a lot, and sure I am working on it.
@ashishbhalgat24824 жыл бұрын
Very well articulated. Thanks
@rajk.4530 Жыл бұрын
Good explanation but you have overwhelmed me with thought, I will recommend initially focusing on one problem design bookmyshow and then jumping into the concept of Market Place. even Amazo has the problem of inventory and sometimes you may get a theatre which doesn't have an online system but they are still selling their ticket on multiple site .
@devarajchennur99114 жыл бұрын
Great explaination ....hats of🤓🤓🤓🤓
@vikashkumarchaurasia12993 жыл бұрын
Great video , best explaination i have ever seen for BMS on youtube. Thanks a lot
@prithviamruthraj5 жыл бұрын
Hey Naren .. 1) in the beginning of the video you mentioned theatre DB. Does that mean the db owned by theatre (and not BMS) ? So any db that needs to on-board to bms should expose lock api right ? 2) there is a db schema that you mentioned at the end. So these tables owned by bms will be maintaining a replica of some details like available seats etc which already is stored in theatre db is it ? Can you please help in differentiating between theatre db and db owned by bms ?
@smbehindyou4 жыл бұрын
correct .. i too have the same doubt ...
@amitprakashpandeysonu4 жыл бұрын
Thanks for nicely explaining each and every details.
@dhananajaykrishna82595 жыл бұрын
Awesome!! Explained really well....Looking forward for many such videos
@MeenaSivan4 жыл бұрын
Like your indepth knowledge and explanaitions!
@shreyansborad99772 жыл бұрын
Really Nice video and explanation
@Everevolvingguy5 жыл бұрын
How to handle when other platforms books ticket. How to update the seat chart please explain that. This is very simple what you explained
@yeehaw-s7kАй бұрын
very useful video,thank you!!
@dvlduvall4 жыл бұрын
Love the dog barking on the background. These are great series. Thank you so much for simplifying the interview process.
@peijia-o8g Жыл бұрын
Very clear system design
@sdvakili6 жыл бұрын
Thanks for the problem explanation. 1. Why is it necessary to cache separately at two tiers, Varnish and backend Cache? 2. What tools would you recommend for handling multi DBs, for promoting a slave to master, etc.?
@TechDummiesNarendraL6 жыл бұрын
1. Varnish can cache and avoid request even hitting the App server. so less server usage. 2. I haven't worked much on RDBMS :|
@sachinshukla60476 жыл бұрын
MySQL routers can route the request to right master node if original master goes down. Application doesn’t need to do that as router takes care of it
@meyavuz6 жыл бұрын
@@TechDummiesNarendraL Thanks for the video. Where does the varnish cache reside? In its own server or in LB server? Also the images and videos of the theaters, should they be stored in CDN? But how fast is it to retrieve from the CDN? Thanks
@ashupu6 жыл бұрын
Please include class diagram, database design and also some basic coding for all the system design . That will help much to visualize all the things behind the scene.
@vedantgunde18813 жыл бұрын
Superb explanation
@stoneshou2 жыл бұрын
I always curious about how to deal with malicious traffic in a system where user can "reserve tickets" for 10 minutes, like, what if someone just reserves every single ticket in the database again and again without paying for them?
@schugh10005 жыл бұрын
In 13:50 you describe NoSQL, but you do not mention what information the NoSQL database holds, which is different from RDBMS in this case? Does the NoSQL database hold images associated with movies or movie schedule?
@subhayu21484 жыл бұрын
awesome detailed explanation cleared lot of technology doubts as well.
@funnybugsbunny4 жыл бұрын
Very detailed. Thanks
@HemantNegi6 жыл бұрын
Great video. I want to understand more about scaling a SQL and No SQL database and how to overcome problems like Replication delay, Consistency, Transactions and Different locking strategies on a highly available distributed database. Please can you make a video explaining this only. Thanks
@sachinpabale5 жыл бұрын
Real good video i saw every video of yours and it really helped me cracking interview of one of the big 4.. i used concepts of this video in my design n architecture, and it really helped me.. keep doing good stuff man..
@nishat2ahmad6 жыл бұрын
Thank you for such a detailed explanation I have two queries 1. As you said there is relationship between entity like movie,Cinema etc that is why we should choose RDBMS,But if read to too heavy should not we choose denormalized database design? As Music player has been designed in Cassandra's official blog. Where as per query table has been designed, of course for booking we can go with RDMS because it will need transaction. 2. I have seen different blogs where they have explained to first calculate TPS and DB sized required,It is really required in interview to calculate tps and db size
@TechDummiesNarendraL6 жыл бұрын
1. Yes you are right RDBMS is must when you need transactions. In case of MOVIE->ACTOR relationships you can use De-normalized database tooo(depends of size and QPS) or you can use RDBMS and a caching layer if reads are more. It is absolutely possible to build relationships using Cassandra with proper data-modeling. 2. It depends, please clarify it with interviewer before you answer(its always good to have DB size calculation as it gives you an idea of what kind of DB you should go for). I also including DB size and TPS/QPS information in recent videos too.
@maggisp35 жыл бұрын
Do they use API's to access the theatre's inventory or DB Connectivity?
@monkwhocodes7904 жыл бұрын
Great videos. Your videos helped me crack interviews at Amazon and Goldman Sachs. Thank you❤️
@vadane14 жыл бұрын
Great video, great explanation
@buvanaanguchamy95892 жыл бұрын
Hi Naren, Thanks for the detailed explanation. Can you please create a video for ticket booking system from Theatere side.
@tapanbehera32245 жыл бұрын
Hi Naren, Can you please write down the technologies you mentioned(at 4:11 min) for handling the requests from BMS server to Theater server? Only Python Async is audible. Other 2 about GO and Lite weight thread are not audible.
@alekseiloginov12905 жыл бұрын
Erlang lightweight threads and Go coroutines
@siddeo85 Жыл бұрын
nice video, understood the basics of system design. Planning to read about each individual unit you briefed in the video.
@jaswantpardeshi90293 жыл бұрын
Thank you for this video.
@vaibhavbhardwaj22444 жыл бұрын
Though the video is good but I think depth is missing - No discussion about concurrent users , Locking and unlocking of seats or the table schema. This video is heavy on the features but light on the technical aspects !
@агатакристи-г3ы5 жыл бұрын
Excellent explanation as usual! Subscribed to channel.
@TechDummiesNarendraL5 жыл бұрын
Thanks alot
@ajitkumarpes5 жыл бұрын
Nice video, Can you please add video for retail website like amazon, When they will have sales how they will manage lots of request and availability of item for particular pin-code and how they will decide one day delivery of item. It will be very helpful if you will add this. Thanks
@RaviChandraEnaganti3 жыл бұрын
In a real world ticketing aggregator, I think the tickets data can either be maintained by the third parties themselves, or the aggregator can also maintain on their behalf. Because all theaters may not be tech-savvy enough to maintain their own IT systems. It is not their core business. Both approaches have their pros and cons.
@arjun.s51124 жыл бұрын
Thank you so much. This helped me !
@rahulsharma50303 жыл бұрын
If we want to store movie information in elastic search for faster search,can we store directly or does it has to go through logstash?I mean log stash is meant for this or only for logs purpose?
@soumyabiswas62514 жыл бұрын
Short and simple - Thank You Narendra :)
@Royalty-x5o4 жыл бұрын
great work keep it up
@krishsrivatsav73085 жыл бұрын
Very useful video tqsm bro
@thorthegreat105 жыл бұрын
Thank you for the video - I love how you did the diagram of all system components. Can you do a follow-up material on how to support that ticket reservation (in more technical details)? I've done an interview with Google recently, one engineer asked this sys desing question, but drilled in depth on that ticket reservation. Details from my interview - user can book up to 10 tickets (sets) at the time, it's reserved for him fo 2 minutes, there must be no collistions (like user 1 sees seat A23 as available, then spend 1 minute to fill the info, but the same seat booked by other user 2 and user 1 got error response)
@mailurvj5 жыл бұрын
I guess following will happen: 1. Call theater's API to get available and booked seats for a movie+show-date-time combination for a theater in a city. 2. User chooses and selects the seats. clicks next. 3. Call Hold API for the selected seats (Hold for 5mins), it'll appear as booked to any users who tries to see available seat. if unavailable return error to user and let them select other seat/ 4. let the user fill all the details, login if was not loggedin, add payment details. 5. This is optional - verify credit card and place hold. if payment can't me held show error to user and let them enter a new credit card. 6. validate seat can be booked and still has hold, if unavailable return error to user. 7. collect payment, if payment can't me collected show error to user and let them enter a new credit card. 8. Mark seat as Booked in theater. 9. Return confirmation to user.
@ankitjain87244 жыл бұрын
Frankly it looks like you are repeating similar content in all system designs. My suggestion would be to focus more on challenges encountered in particular design first and then, other things like async workers, queues, ML models e.t.c can be added. I was expecting more discussion on transactional nature of the problem, and how we can scale that. Btw I love your system design content and have watched many of them :)
@nishantraithatha87016 жыл бұрын
great job in detailed explanation
@moonbrush52 жыл бұрын
Ok so NOSql will have distributed data. But I didn't get what are those distributed data? Can someone give example for the above system design what will be distributed data that will be stored in NOSql.
@mahahrishi10 ай бұрын
Hi Narendra, Thank you for the insightful video on system design. However, I wanted to point out that BookMyShow primarily functions as an aggregator. Therefore, the actual seat availability and booking processes are likely managed by third parties or partners, such as Inox, who handle the ticket reservations. Could you consider creating a video explaining how such aggregators communicate with multiplexes or chains of multiplexes, how they display showtimes and seat availability in real-time, and how they facilitate real-time ticket bookings?
@sushmitagoswami73203 жыл бұрын
Can you please break the design into microservice? Thank you for all your efforts. It is really worth watching.
@lemonginger0015 жыл бұрын
how does bookticket api keep track of payment done by different api
@ameyapatil11394 жыл бұрын
Superb ! Great video.
@JM_utube4 жыл бұрын
awesome video thank you so much
@anithaselvan77225 ай бұрын
One doubt. BMS has its own rdbms db that stores all the info related to movies, shows, seats etc. It calls the theatres API only to lock the seats. So would the rdbms db be constantly updated with the seats booked and other info? Because seats could be booked from other sites as well.
@yashshah73925 жыл бұрын
Hi Narendra, i am currently working on movie ticket booking system and I want to know that is there any APIS available for listing latest movies and get seat availability of movie and book seat of particular movie. i also want to know that is there any way to reach out all theater's database? Thanks
@SwapnilSuhane5 жыл бұрын
awesome ..covered almost all design aspects..
@kishrazor6 жыл бұрын
Thanks for the detail explanation,it is very useful.
@parthacnp2 жыл бұрын
Did you post Amazon like e commerce system design?
@pha19943 жыл бұрын
What will be cached on Varnish or the back cache? Is there any scalable caching strategy if millions of people are locking or unlocking the seats?
@321zipzapzoom4 жыл бұрын
Awesome explanation..just one quick question which I have is..how to handle increased number of users logging in accessing the booking flow from concurrency perspective..thanks again mr. Naren
@abhigyannayak41515 жыл бұрын
I have couple of queriee. 1. Locking system seems to provide inconsistent information to users. What if the user did not book the ticket. But the seat was locked. It shows unavailable to the another users. But would be available after 15 minutes. 2. How would NoSQL and SQL database interact with each other. Comments are relatable to users. But we are storing comments on NoSQL and user information on SQL database.
@SandeepPatel-fy8id5 жыл бұрын
yes, it would be available after 15 minutes.
@vijayrathore1004 жыл бұрын
Hi I have one question. The theater tiket booking is managed by bookmyshow or they have thier own database and sever.
@arjunkadayaprath51656 жыл бұрын
Thanks a lot for the information. This was very useful. I just have a quick question on the theater server side. Who maintains information on the theater server side? In case of BMS, do we have a generic API in the theater side? Or do we have to implement it in the theater side as well if we have to support a particular theater?
@TechDummiesNarendraL6 жыл бұрын
PVR/INOX like big theaters companies have their own ticket booking application, so as a theater aggregator service we need to work along with their system/APIS. But some small scale theaters will not usually have ticketing systems. in that case we will have to provide some sort of service/server to let them know what tickets are occupied/free.
@chughcs12 жыл бұрын
can you please expalin how the Theatre DB and BMS db are interacting
@venkateshpachigulla2 жыл бұрын
While dessigning are we not to suppose to include admin portal of BMS or anything else? Or The designing of BMS admin portal(entering movie details) has to go in a separate way?
@rahulchudasama93634 жыл бұрын
How seat data will be stored? It uses bit array? Or something like that? Expecting one simple example.
@prudeabhi6 жыл бұрын
Thanks a lot sharing your in depth knowledge regarding the BMS. I will highly appreciate if you could answer one of my query , how do we put a lock on the specific seat for a specific time interval
@TechDummiesNarendraL6 жыл бұрын
Every seat is a row in Seats table. U can use Redis(cache) or cassnadra(nosql) which comes with default Time to live(TTL) you can use this. But it's not simple when you have distributed system. Take a look at this article for more info redis.io/topics/distlock
@prudeabhi6 жыл бұрын
Tech Dummies thanks a lot for sharing the info, and keep making some more design videos. Love your explanation
@prakashnandihal86553 жыл бұрын
@@TechDummiesNarendraL How can i lock row in a table if i am using RDBMS
@PrashantGupta-mq4hw3 жыл бұрын
great job! sir
@tarunkr.90415 жыл бұрын
Love your efforts
@mohitg71516 жыл бұрын
You are doing a good job explaining high level overviews of architectures. This can be improved by reducing each video to byte-sized videos based on a concept or by provding duration markers.
@TechDummiesNarendraL6 жыл бұрын
Yeh, you are right. Time consuming but possible. Considered :)
@MrJaswant104 жыл бұрын
Hi Narendra , you have explained the session very well. I am your consistent viewer/user and follow your all system design related series and concept.
@thesadanand65994 жыл бұрын
Hi Naren, No need to lock the seat right, ? its only read-only, unitll i pass-through the payment flow.... ?
@TechDummiesNarendraL4 жыл бұрын
Locking as soon as the user selects the seats gives much predictable behavior for users, and start time to finish payment flow. Otherwise you will have to double check before you start the payment flow.
@ambermani16674 жыл бұрын
8:52 if VARNISH is frontend caching system then why load balancer is talking to VARNISH?
@jonpliske4 жыл бұрын
Varnish acts like a transparent caching reverse proxy in this case. The URL string (typically without e.g. query params) is the cache key. If the key is not present, reverse proxy the request to the backend service and cache the response. To a user this is invisible, minus a difference in latency on cache miss. This is very similar to how a CDN is used, though implementation of CDN is typically more complicated.
@pushpak39814 жыл бұрын
Thanks for such valuable information and time brother. :)
@Asha-se4wv3 жыл бұрын
question : how new movie/movie trailer upload flow will work?
@viralmehta25423 жыл бұрын
what does synchronous calls and asynchronous calls mean?
@ApunKaTimeAyega5 жыл бұрын
Hi Narendra , I am big fan of your system design videos. I have question here. Since BMS follows micro service architecture, a comment or like by 2 users(geographically located at 2 different places) may be handled by two different servers. Then how does system ensure the consistency for number of comments/likes. Will system be eventual consistent ?
@Shashankurade5 жыл бұрын
Great video!! I had been asked this question in Amazon's interview for SDE2 role. They expect a lot much from a low-level design perspective like class diagram. You mostly cover HLD please cover component level design as well. Thoughts??
@zhouchong905 жыл бұрын
Shashank Urade I think the fields/class diagram is very simple. He’s mostly teaching architecture design. If you understand all these, try to shoot for a SDE3 or Principal SDE in Amazon and they’ll ask you the same.
@reshmayasmin97174 жыл бұрын
Why do we need to have nosql db physically at our end? If theater gives api , we can directly hit the Api , send movie name and it will fetch all movie information directly from theater Api. So.why do we need nosql at BMS end?
@msbollywoodfilmequipments79496 жыл бұрын
Hi , can you tell what is the cost coming for like this system making with apps ?
@buddhadeb285 жыл бұрын
How provide server to cinema hall owner?Is it provide by book my show or paytm company or it is to buy hall owner ? Plz help
@SunilGupta-ki2qw6 жыл бұрын
Very well explained :)
@chabhishyam5 жыл бұрын
Very Good Information. Thank you so much for the nice content. One question from my side. U have mentioned that we can user elastic search for searching of movies, theaters, etc. So from where the elastic search will consume the data..? I mean what will be the input data source?
@MrBkjain4 жыл бұрын
Hi Narendra, A great video again from your end. You are doing a fab job and I am very much thankful to you for doing this. I had a couple more questions to clear my doubts. 1) For ticket booking, is it just one service as shown by you running multiple instances of it in different application servers that are responsible to do so or that is also segregated in multiple different Microservices e.g. I didn't find any mention of having a User service, Payment service, Login service, Authentication/Authorization, etc? Is that given? 2) I do see that you have mentioned the Payment Gateway connectivity with JusPay but isn't that a limitation if we go via that route and shouldn't that be wrapped inside a service that we own instead of just invoking the Payment gateway in MS architecture? 3) I do see that you have mentioned Async workers but not sure about the overall processing and how these Async workers will be invoked and communicated in a sequence/activity diagram while booking the tickets? If you can share more details?