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

Affiliate Disclosure:When you buy via links on our site, we may earn an affiliate commission at no extra cost to you.

Learn how to system design BOOKMYSHOW or FANDANGO or Online ticket booking system.
One of the famous interview question in companies like Linkedin, facebook and many startups.
Here is the system design diagram :

#bookmyshow #systemdesign #architecture #interviewpreperations #amazoninterviews
#interviews #learnsoftwaredesign


amazing-BOOKMYSHOW System Design, FANDANGO System Design | Software architecture for online ticket booking
amazing-BOOKMYSHOW System Design, FANDANGO System Design | Software architecture for online ticket booking
  1. 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.

  2. 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.

  3. This comment is just to show my frustration with youtube. Anytime I search system design, though I have not subscribed, youtube shows this channel links.
    I see many of these system design are incomplete,
    1. For God's sake talk about the micro services which you will use, and interactions.
    2. Talk about Sags's first or if you are using two phase commit mention those.
    3. Talk about the informations which you would like to cache, for example I know for some movies m1, some ticket s1 is already locked the tickets, so try to cache that information. If some user u1 did not complete his booking use that same information to assign that ticket to some one else who is trying to book the same ticket.
    4. Talk more about the schema design which you will use like tables, columns at high level.
    5. What is the need of mentioning ec2, s3 or cloud flair, because you have completed some course or worked on aws? These system design should be cloud ready not specific to aws or azzure or anything.
    3. What about the security? I don't see a single word about security here.
    4. This video is two years old only. What is the use of mentioning go routine or python based servers or node js. Any reactive servers has kind of similar performance now.
    5. Mysql explanation was not even necessary.
    6. Any NoSql data uses clusters, now when you are mentioning nosql what is the need of showing sharding or consistent hashing thing drawing. 🤔
    7. Notifications are events for which do we need queue? I guess no, kafka is better candidate. 🤷

    Plus there are others who have also mentioned few things, I am coping them here again.

  4. exact copy from geeks for geeks but nicely explained

  5. I feel like this is all a bunch of tech jargaon without resolving the core CS issues. For example, Rajnikanth's Enthiran comes out, and everyone wants to see it. Locking a DB row for 10 minutes while others are waiting is going to be huge loss of business. Also, the ticket availabilities need to be shown as real-time as possible. The CS challenge here isn't big data, it's massive concurrency, which isn't discussed at all.

  6. @Narendra at 13:13 , If we keep master slave architecture. How do we address below :-
    1. We will loos geo located/near data for all writes, as all servers would be connecting to this single master
    2. What is the good way to handle fault tolerance if our master node dies ?

    And also can you please explain in detail, how do we handle lock on a seat to prevent concurrent booking.

    And yes, thanks a lot for the video 🙂

  7. Can you please break the design into microservice? Thank you for all your efforts. It is really worth watching.

  8. Good video. API details was not spelt out.

  9. Those were the days when you could say "master and slaves" and nobody would lose their minds. Now it’s "primary vs secondary", "allowlist vs denylist" (lmfao)

  10. This is nice. I see app servers never talks to rdbms or nosql db directly. There could be lot of scenarios where I have to hit db directly instead of always the cache route.

  11. @Narendra L Very insightful! Lot of concepts here to explore further! Wouldn’t a “API gateway” do the job better than ( a superset solution ) Varnish cache here?

  12. 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?

  13. can we update these components s per new techstacks

  14. Hi Narendra, You explained very well. Well, the basis on the explanation, Would you please cover the scenario that If, the theaters would have their own booking system and they are taking bookings from various sources such as Book my show, Paytm and so on then how it would work ? Also, the counter question is.. how to handle the same request at the same time from two or more sources?

  15. how to get theater database ?

  16. "why the fuck that accent" saying in your accent :/

  17. Great video , best explaination i have ever seen for BMS on youtube. Thanks a lot

  18. Thanks Narendra for the video. I would highly recommend not to watch this video as it just talks about technology and missing the core features on how to book seats, handle active reservations, expired reservations, waitlist etc. Finally the important concept of handling concurrency. This is not helpful for real interviews, trust me.

  19. Really Nice video and explanation

  20. Can you make this video again but this time with more detailed explanation.

  21. Hi Naren, Thanks for the detailed explanation. Can you please create a video for ticket booking system from Theatere side.

  22. can you please expalin how the Theatre DB and BMS db are interacting

  23. Designing bunch of tables for each component is easy enough. IMO, he didn't solve the heart of the problem: high concurrency – just saying ACID/MySQL for the high concurrency is not enough. For example, what if the app server fails immediately after confirming the payment, so it couldn't write to the DB to reserve the seat? We told customer that we reserved his/her seats, but another person books the seat. This is really bad.

  24. Did you post Amazon like e commerce system design?

  25. Pakistani calling AFRICA a Country. Congratulations

  26. 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?

Leave a reply

Compare items
  • Cameras (0)
  • Phones (0)