I have watched all of your system design videos (till now) on a single seating. Not that I am particularly preparing for interviews, I just find them interesting. You should continue making these contents. These are rich and practical. Keep it up.
better to take time , dont take single seating lectures. if you take 2 or 3 per day you have chance of thinking on topic and you can relate to real time applications
Yes, I agree. I already know everything that is covered in this playlist from my regular work. But, still the topic is interesting and the content is engaging.
2023 and this video is still helping out! I'm just new in the software engineering world and yet you've managed to discuss monolithic and microservice systems in a way that even a newbie can understand. I also appreciate the references you've left in the description for further reading. Thank you for this.
Monolith - Single/Multiple machine running the computation Microservice - It's a division of whole works into business units which are turned into specific microservice. Adv Monolith: - Less moving parts - Good for small teams - Less duplication for tests etc - Faster because everything is in same box(procedure calls) Disadv Monlith: - Require more context - Deployment is complex (everything is touching every other thing) - Too much responsibility on one server (one can break everything) - Tight coupling Adv Micro: - Easy to scale - Less context required - Parallel development is easy - Less hidden parts(more resources can be provided where it is required) Disadv Micro: - Tougher to design Most of the times interviews are high scale and hence micro service is preferred Thanks for video 😄
This is a very nice channel. Nice work Gaurav. :). My 2 cents :) Monolith Advantage / Microservices disadvantage. 1. Transaction management. 2. One does not have to deal with multiple technology stacks. 3.There is no need to maintain code at the same level for all the services. You don't need to pass on a jar to other services in order to enable resue of code. 4. Latency (as mentioned in the video) Microservices advantages 1. No single point of failure. 2. You can use the correct technology stack for the required microservice. 3. Decentralized architecture. 4. Decentralized data management. 5. No need to redeploy the whole application. Deployment is faster and easier. 6.Your microservices should be designed across products. SOA is designed around features. This way of thinking is more customer centric.
Very good explanation in short video .Just adding few more points of my understanding Monolith is a single application build for many systems. In Monolith if any modifications done in the code the whole application should be build and deploy. In case of my microservices only the modified microservices will be deployed. Monolith uses local calls for interaction where as microservices will use network calls. So here Monolith will give better performance as compared to microservices. Testing will be easier in microservices because we test only modified microservice . In case of Monolith if any changes done need to perform the functionality testing of whole application to make sure application is working as expected.
Good video but missed some key points in favour of micro services example A. You can design a system with different technologies. B. You do not have to scale the entire system when load is high on just one function. C. Micro services support DevOps which enable CICD..... Also a microservices design are created using Domain driven design which also maps to the actual business function. To maintain separation of accountability I can have 2 microservices even in the case you mention.
If you don't mind me (politely) asking: Why wouldn't a monolith be compatible with CI/CD, on your point of view? Genuinely curious here, so I'd like to know your point of view on it.
@@arthuraguiar5382 It's not that it wouldn't be compatible, but ANY change to the code would result in ALL of the code being built/redeployed. If you have them split into separate services, it's much less to build/deploy at any given time.
I want to be able to communicate and speak like you do...You smile so much and have so much charisma...I refrain from smiling most of the time cause I look weird...Idk why! Thanks for inspiring me to improve 🙏🙏
I teach CS and I like your way of explaining things, you are clever and that positive attitude and smil!. Your chuckle in 7:50 :D is so cute. Keep it up
Thanks Gaurav. Excellent videos. Though I would like to argue with a statement you are making about microservices vs. monolith. Not just you. Everyone makes this statement about microservices. Microservice architecture is easier for onboarding new members because they need less context - is just a false statement. Within monolith we can equally identify classes or packages that new developers need to work on without knowing about the rest of the system. Classes within monolith can be tested using unit tests. Microservices need to be tested with integration tests - they are harder to write. If system is monolithic it doesn't mean that we shouldn't reduce coupling between classes and increase cohesion with in classes. Linux is a monolithic architecture, but Linus speaks a lot about how important it was for them to come up with independent parts inside the kernel. So that these independent parts can be modified without knowing about the rest of the kernel. So ease of onboarding of new members is not really a feature of microservice architecture.
Monoliths are also need to be tested with integration+system testing. That is not specific to microservices. "Within monolith we can equally identify classes or packages that new developers need to work on without knowing about the rest of the system". This comes out of the box with microservices, so no one has to identify those classes which makes it easier to onboard new developers. Also a in order to develop a monolithic application, a new developer needs to install and configure all the required applications like IDE's, plug-ins, DBMS', message queues, web servers etc. Assume a microservice that does not use MS SQL Server, then the developer won't be needed to install/configure that which again makes it easy for the new developer. Another thing is when developing monolithic applications, there is always a greater procedure for developing, testing, code reviewing and deployment. With microservices, only a subset of those procedures are needed. Again this is better for the developer.
Thanks Gaurav. Yes, Monolith is complex to understand completely in one go and basically tightly coupled. But the point that is a strong advantage there is apart form the fact that procedural calls are faster, in micro service architecture sometimes a service is dependent on too much on other services and when it comes to logging you also need to track the flow of all your calls plus they add an extra network cost, you need to handle all the failures, have retry logic and fall back in place.
Hey Gaurav, I am going thru your videos around System Design, they are really crisp and clear. Thanks for your efforts. Regarding micro-services, I would like to add a few pointers. 1. Even with Larger Systems, sometimes micro-services may not be always a good fit. For example, in stream processing systems where processing is centered around per record based processing and micro service calls would worsen the performance. 2. Deployment of micro-services is far more complicated than monoliths. Because usually with Monoliths, it's a single unit of deployment(Eg: war file if WebApps) but with microservices depending on the scale and grain of the micro-services, there will be N number of deployments needed. It becomes difficult to keep track of the status of each service and in turn, knowing the readiness of the overall system will be a challenge. 3. Microservices are a great fit for mobile and web applications but when it comes to Big-Data world, it would complicate the overall process. For example, In the Web applications, we mostly deal with Web Server, Database and its easier to containerize them but when it comes to distributed systems containerizing them will be a challenge. I am not against of micro-services but wanted to list down few scenarios where micro-services may not be a great fit.
Great complement. Very well explained. I think we have to be very careful when choosing the architecture. Different kind of problems may demand different ways to solve them.
Load balancing is very difficult in Monolith. Example, take Flight reservation system application as example. Every body uses search page to search flights. But only few goes to the booking of a searched flight. So search operation is taking too much load on that. So In Micro services, We can create as many instances as we can of Search micro service alone. I agree deployment and monitoring is very difficult in Micro services , but using Eureka or Spring admin console, we can have all the instances and monitor them easily. For small scale application development which scaling is not required, then Monolith is best.
+1 for second bullet point. Deployment of micro-service can be faster since it's a smaller unit of deployment, but coordination of multiple micro-services deployment can be pain in the ass.
man.. I'm in the e-commerce business, and so grateful to watch and learn from this content.. thanks a lot for sharing, hope you can share more about IT world! Big Up!
Really well done, concise is the word to describe this video. Since the topic is so well handled viewers can genuinely use this information to make decisions and analyze the need for a mono or micro for a system. So stackoverflow is a monolith that handles a massive load of questions on microservices.
In my opinion, "MonolithFirst", by Martin Fowler is the best approach to start a new project for current scenarios. Because the high competitiveness (short deadlines) and low project budgets (small teams and limited resources).
Just want to add one more advantage of micro service. As time progress, our software product also gets new features/modules etc. Our software customers also expand their business and buy new modules/features. Example in Banking, we now have online support, online banking, mobile banking etc. There may be some customers who do not want new modules. Example a bank do not have plans to roll out mobile banking application yet. So they do not want new modules. When we try to sell our software product, customer will not be interested in buying all the modules as they may not be working on all of them. Example - In banking, small banks may not be providing credit cards. So they do not want credit card module. Some customers want to just replace a particular module in their ecosystem as they find out that our product works better. in that case they want to deploy only that particular module. Example - Loans module in our banking software product works best in the competition and customers want to buy only that. They do not want to replace their online banking product. So microservice architecture makes sense as it gives lot of flexibility and also cost wise. It can also be easily used to plug it with other systems that customer might already be working with. We can provide new features as and when they require it.
Hi Gaurav, Thanks for your efforts it was a good video. Following are few pointers which i would like to add 1) Monolith application can co-exist with microservices. What i mean here is that suppose if you have a large application which uses a MVC framework then the same application can also use a common services provided by a microservice. 2) Microservice architecture also has its own set of challenges in terms of maintenance and deployment. The Netflix architecture video about Mastering chaos discusses some problems. 3) Now a days the industry does not want a team to only focus on one thing and would like to have a small development team managing multiple application. Too cut costs can be one of the reasons. 4) With the advent of MVVM frameworks on client side like angularJS which performs a lot of processing on the client side would be better complemented with microservice architecture. Once again Keep up the good work
I really like your explanation. For more clarity and better perspective I still have concern around MS architecture vs Monolith - 1 How is cost benefit ? Ms needs at least 2 developer (what if one quits ) working on each service ? You need as many host servers as you have services 2 You need to tack the flow of calls across call stack services . How about transaction ? 3 Code duplication is sure shot, data redundancy too . 4 you need backup plans , alerts monitoring for all these instances 5 For long run more maintenance cost At the end the benefit I found is instead of all services going down in Monolith only few will go down in Microservices Less customer impact.
Yes definitely agreed with you. Continuous communication of developers is required. Microservices are costly and the complexity levels are comparatively high .
Made it this far starting from your first system design video in a single seating, I had never been this interested in studying before( hyperbole) and maybe I'll watch a few more : P. Thanks a lot!
Gaurav , your enthusiasm and such detailed explanation with all cons and pros makes your videos amazing. I often go through them in my free time because not only it makes me think a lot but its fun too.
I can give one example that why scaling factor is more important in micro services, lets say we have cart service and simple login service of ecommerce, now we know login service will have less traffic while cart service has lot of traffic during sales than logins, definitely if keep both of them in monolith, we can't scale them properly, clearly we can see that traffic on cart APIs will be much higher than normal APIs, so lets create different service for cart ;) and scale them differently by providing bigger and more servers to this micro service, that shows how important a micro services is :)
I am also thinking like you. Let us consider we have 1000 cores CPU(100 servers with 10 cores load balanced) overall in monolith. At any given time at high load scenario, 80% resource is utilized by cart service and remaining 20% will be utilized by other services. If can track all the calls and the time taken, we can get to know the resource utilization by each feature. All I am saying is, The requirement for scaling a monolith will come from higher load (We will not be sure about which feature is used more.) When we scale up, whatever the feature which was called a lot will be served easily without affecting others.
A very big advantage of microservices is that they are very easy to maintain, test and deploy. CI and CD are much more possible with a microservice architecture. You probably discussed that, and maybe I missed it. Good summary.
Lots of good information. In practice I also see efforts around starting off with micro services and move some into bigger services when it makes sense
main advantage of microservice is: scalability. you have freedom to scale x microservice while y remains at same capacity. While in monolith, whole system scales. But one disadvantage of microservice is handling transactions. If you are having architecture like your transaction is spread across various microservices. its not good. Please share your thought.
Monoliths kind of get a bad rap so I appreciate the more balanced answers here. If you're a small team the overhead of spinning up services can be a bigger deal and it can make less sense.
I believe decoupling is not something only found in microservices. Infact even if it's a single process a good programmer has to deside on what the components of the system are and decouple them with interfaces. One could even do independent deployability in a monolith by having the system components built in dll files instead of having them built statically. A new developer doesn't have to understand the entire code, just the component they are working on and the interface contract on how it interracts with the other components.
Thank you for such contents to give good exposure of how things actually work. I have watching the whole playlist as I have an interview tomorrow. Hoping this works out for me. Thank you!
Thanks Gaurav for these excellent videos, really helped me a lot understanding some concepts. It would be really great if you could make a video where you code this stuff because theoretically everything makes sense but actually making a good system design out of a business requirement becomes a bit hard. So, it would be great to see how you design an actual system in terms of classes, DB etc. and how you decouple stuff. I know there are ton of videos out there but your style is really understandable for me. Thanks again.
Your way of explaining things is so natural and easy to follow although I don't do lot of coding. I guess you have a great future as fantastic teacher Gaurav, something really needed for our Indian education system where focus is mainly on clearing exam without knowing the concept + application of the technology. Keep coding and keep teaching :-)
Microservices allows to be programing language poliglot, and data store poliglot, this is a great advantage to take the best of the programing language for each use case, and poliglot data store to get the best benefit of the different data store (rdbms. nosql, files, key value, etc) dependeing of the use case for the microservice.
Hi Gaurav, Thank you so much for this Excellent knowledge. I would like to request you, Please make the videos on the Microservices design patterns. Thank you
Microservices has all the associated complexities of the distributed system. There is a higher chance of failure during communication between different services. Difficult to manage a large number of services. The developer needs to solve the problem, such as network latency and load balancing. Complex testing over a distributed environment.
Hi Gaurav, Please add a video on what should be a developer's approach for using threading (extensive threading or moderate thraeding) and its consequences.
The role of a Solution Architect is to actually design system in such a way that separate concerns should be designed as separate Microservices. The criteria of having a single consumer of a service or a small team to manage the application probably not a justification to ditch the Microservices design. Consider a small startup designs a Microservices app and invites contributors to enhance, integrate with other services, or simply the product is acquired by a big company to use with its other products. Furthermore, network calls among Microservices is not a major issue when deployed on same host, inter-process communication can be achieved through different strategy of developing Microservices clients. In my humble opinion, Microservices should always be used, even a monolithic application should be developed with some provisions of Microservices.
excellent explanation..not sure who (and why) is disliking the video! I just hope that, its a click by chance on the "dislike" button! Keep it up Gaurav! I am just loving these technical vidoes- as it helps me-who can't understand new things on the first go and searched for many easy-to-understand articles/videos! :-)
Well explained! Just one comment: in this video it is implied a little bit that a bad coupling among functions exists in monoliths. Actually unnecessary (bad) function coupling can exist in either microservices or monoliths. Choosing microservices doesn’t give us well decoupled functions automatically. Even worse, tangled functions among microservices make everything even harder than if same situation happens in monoliths. So no matter microservices or monoliths, be careful about dependencies. BTW, a lot of successful monoliths have good design with clean, decoupled modules/functions. The video also mentioned separating concerns according to business responsibilities. So my comment is just an add-on to emphasize/clarify the point about possible complexities of coupling through libraries or runtime calls in microservices. Thanks for posting this nice video!
![[#2024MAMA] BIGBANG (빅뱅) - 뱅뱅뱅 (BANG BANG BANG) + FANTASTIC BABY | Mnet 241123 방송](http://i.ytimg.com/vi/EQsYfiPR9uM/mqdefault.jpg)
I have watched all of your system design videos (till now) on a single seating. Not that I am particularly preparing for interviews, I just find them interesting.
You should continue making these contents. These are rich and practical. Keep it up.
Thanks!
better to take time , dont take single seating lectures. if you take 2 or 3 per day you have chance of thinking on topic and you can relate to real time applications
This is probably one of my few youtube comments, but this is exactly what I did. Very informative and concise playlist.
I second that
Yes, I agree. I already know everything that is covered in this playlist from my regular work. But, still the topic is interesting and the content is engaging.
2023 and this video is still helping out! I'm just new in the software engineering world and yet you've managed to discuss monolithic and microservice systems in a way that even a newbie can understand. I also appreciate the references you've left in the description for further reading. Thank you for this.
Monolith - Single/Multiple machine running the computation
Microservice - It's a division of whole works into business units which are turned into specific microservice.
Adv Monolith:
- Less moving parts
- Good for small teams
- Less duplication for tests etc
- Faster because everything is in same box(procedure calls)
Disadv Monlith:
- Require more context
- Deployment is complex (everything is touching every other thing)
- Too much responsibility on one server (one can break everything)
- Tight coupling
Adv Micro:
- Easy to scale
- Less context required
- Parallel development is easy
- Less hidden parts(more resources can be provided where it is required)
Disadv Micro:
- Tougher to design
Most of the times interviews are high scale and hence micro service is preferred
Thanks for video 😄
nice 👍
As a SWE1, this is the perfect channel on TH-cam. Thank you!
Thanks 😁
This is a very nice channel. Nice work Gaurav. :).
My 2 cents :)
Monolith Advantage / Microservices disadvantage.
1. Transaction management.
2. One does not have to deal with multiple technology stacks.
3.There is no need to maintain code at the same level for all the services.
You don't need to pass on a jar to other services in order to enable resue of code.
4. Latency (as mentioned in the video)
Microservices advantages
1. No single point of failure.
2. You can use the correct technology stack for the required microservice.
3. Decentralized architecture.
4. Decentralized data management.
5. No need to redeploy the whole application. Deployment is faster and easier.
6.Your microservices should be designed across products. SOA is designed around features. This way of thinking is more customer centric.
Very good explanation in short video .Just adding few more points of my understanding
Monolith is a single application build for many systems.
In Monolith if any modifications done in the code the whole application should be build and deploy. In case of my microservices only the modified microservices will be deployed.
Monolith uses local calls for interaction where as microservices will use network calls. So here Monolith will give better performance as compared to microservices.
Testing will be easier in microservices because we test only modified microservice .
In case of Monolith if any changes done need to perform the functionality testing of whole application to make sure application is working as expected.
Thanks Pavan!
correct 👍
Now that's what I call method teaching. This is brilliant. Thanks for helping all of us.
You are gem on this programming world bro.... keep this up... Although I am a frontend guy, I get interest in backend bcz u teach very easy way...
Thank you!
Good video but missed some key points in favour of micro services example A. You can design a system with different technologies. B. You do not have to scale the entire system when load is high on just one function. C. Micro services support DevOps which enable CICD..... Also a microservices design are created using Domain driven design which also maps to the actual business function. To maintain separation of accountability I can have 2 microservices even in the case you mention.
Good points!
If you don't mind me (politely) asking: Why wouldn't a monolith be compatible with CI/CD, on your point of view? Genuinely curious here, so I'd like to know your point of view on it.
B is mentioned
@@arthuraguiar5382 It's not that it wouldn't be compatible, but ANY change to the code would result in ALL of the code being built/redeployed. If you have them split into separate services, it's much less to build/deploy at any given time.
I want to be able to communicate and speak like you do...You smile so much and have so much charisma...I refrain from smiling most of the time cause I look weird...Idk why! Thanks for inspiring me to improve 🙏🙏
I teach CS and I like your way of explaining things, you are clever and that positive attitude and smil!. Your chuckle in 7:50 :D is so cute. Keep it up
Thanks Gaurav. Excellent videos. Though I would like to argue with a statement you are making about microservices vs. monolith. Not just you. Everyone makes this statement about microservices.
Microservice architecture is easier for onboarding new members because they need less context - is just a false statement. Within monolith we can equally identify classes or packages that new developers need to work on without knowing about the rest of the system. Classes within monolith can be tested using unit tests. Microservices need to be tested with integration tests - they are harder to write.
If system is monolithic it doesn't mean that we shouldn't reduce coupling between classes and increase cohesion with in classes. Linux is a monolithic architecture, but Linus speaks a lot about how important it was for them to come up with independent parts inside the kernel. So that these independent parts can be modified without knowing about the rest of the kernel.
So ease of onboarding of new members is not really a feature of microservice architecture.
Agree. I read an article a couple of days back on this. Was planning to share it on Twitter tomorrow.
What a coincidence 😁
thank you for your concern!
@@gkcs which is the twitter post?
@@gkcs which twitter post?
Monoliths are also need to be tested with integration+system testing. That is not specific to microservices.
"Within monolith we can equally identify classes or packages that new developers need to work on without knowing about the rest of the system". This comes out of the box with microservices, so no one has to identify those classes which makes it easier to onboard new developers.
Also a in order to develop a monolithic application, a new developer needs to install and configure all the required applications like IDE's, plug-ins, DBMS', message queues, web servers etc. Assume a microservice that does not use MS SQL Server, then the developer won't be needed to install/configure that which again makes it easy for the new developer.
Another thing is when developing monolithic applications, there is always a greater procedure for developing, testing, code reviewing and deployment. With microservices, only a subset of those procedures are needed. Again this is better for the developer.
Thanks Gaurav. Yes, Monolith is complex to understand completely in one go and basically tightly coupled. But the point that is a strong advantage there is apart form the fact that procedural calls are faster, in micro service architecture sometimes a service is dependent on too much on other services and when it comes to logging you also need to track the flow of all your calls plus they add an extra network cost, you need to handle all the failures, have retry logic and fall back in place.
Thanks @Kunal
Hey Gaurav, I am going thru your videos around System Design, they are really crisp and clear. Thanks for your efforts.
Regarding micro-services, I would like to add a few pointers.
1. Even with Larger Systems, sometimes micro-services may not be always a good fit. For example, in stream processing systems where processing is centered around per record based processing and micro service calls would worsen the performance.
2. Deployment of micro-services is far more complicated than monoliths. Because usually with Monoliths, it's a single unit of deployment(Eg: war file if WebApps) but with microservices depending on the scale and grain of the micro-services, there will be N number of deployments needed. It becomes difficult to keep track of the status of each service and in turn, knowing the readiness of the overall system will be a challenge.
3. Microservices are a great fit for mobile and web applications but when it comes to Big-Data world, it would complicate the overall process. For example, In the Web applications, we mostly deal with Web Server, Database and its easier to containerize them but when it comes to distributed systems containerizing them will be a challenge.
I am not against of micro-services but wanted to list down few scenarios where micro-services may not be a great fit.
Good points Shivaprasad! I think some of these were addressed in the video too :)
Kubernetes helps with orchestration of containerization while ISIO is a service mesh. I don't think they will help with deployments.
Great complement. Very well explained. I think we have to be very careful when choosing the architecture. Different kind of problems may demand different ways to solve them.
Load balancing is very difficult in Monolith. Example, take Flight reservation system application as example. Every body uses search page to search flights. But only few goes to the booking of a searched flight. So search operation is taking too much load on that. So In Micro services, We can create as many instances as we can of Search micro service alone. I agree deployment and monitoring is very difficult in Micro services , but using Eureka or Spring admin console, we can have all the instances and monitor them easily.
For small scale application development which scaling is not required, then Monolith is best.
+1 for second bullet point. Deployment of micro-service can be faster since it's a smaller unit of deployment, but coordination of multiple micro-services deployment can be pain in the ass.
man.. I'm in the e-commerce business, and so grateful to watch and learn from this content.. thanks a lot for sharing, hope you can share more about IT world! Big Up!
Successfully performed 32 post request to the db in my head in one go, you are awsome broo
Your channel is the best place to learn backend engineering 🙏
Managing several micro-services databases could be on a long run challenging. Great explanations! Hope MIT calls you as a special guest to lecture. :)
Some day perhaps 😁
Really well done, concise is the word to describe this video. Since the topic is so well handled viewers can genuinely use this information to make decisions and analyze the need for a mono or micro for a system. So stackoverflow is a monolith that handles a massive load of questions on microservices.
Really a clear-cut explanation of some of the advanced topics!! Keep it up!
Thanks Anubav!
These videos along with the comment section is giving me greater insights about system design. Keep up bro. 🔥
In my opinion, "MonolithFirst", by Martin Fowler is the best approach to start a new project for current scenarios.
Because the high competitiveness (short deadlines) and low project budgets (small teams and limited resources).
Makes sense 🙂
All my life i worked on client side! these are gem concepts videos! thanks!
Just want to add one more advantage of micro service.
As time progress, our software product also gets new features/modules etc. Our software customers also expand their business and buy new modules/features. Example in Banking, we now have online support, online banking, mobile banking etc.
There may be some customers who do not want new modules. Example a bank do not have plans to roll out mobile banking application yet. So they do not want new modules.
When we try to sell our software product, customer will not be interested in buying all the modules as they may not be working on all of them.
Example - In banking, small banks may not be providing credit cards. So they do not want credit card module.
Some customers want to just replace a particular module in their ecosystem as they find out that our product works better. in that case they want to deploy only that particular module.
Example - Loans module in our banking software product works best in the competition and customers want to buy only that. They do not want to replace their online banking product.
So microservice architecture makes sense as it gives lot of flexibility and also cost wise. It can also be easily used to plug it with other systems that customer might already be working with. We can provide new features as and when they require it.
Hi Gaurav, Thanks for your efforts it was a good video.
Following are few pointers which i would like to add
1) Monolith application can co-exist with microservices. What i mean here is that suppose if you have a large application which uses a MVC framework then the same application can also use a common services provided by a microservice.
2) Microservice architecture also has its own set of challenges in terms of maintenance and deployment. The Netflix architecture video about Mastering chaos discusses some problems.
3) Now a days the industry does not want a team to only focus on one thing and would like to have a small development team managing multiple application. Too cut costs can be one of the reasons.
4) With the advent of MVVM frameworks on client side like angularJS which performs a lot of processing on the client side would be better complemented with microservice architecture.
Once again Keep up the good work
Great points Venkatesh!
I really like your explanation. For more clarity and better perspective I still have concern around MS architecture vs Monolith -
1 How is cost benefit ? Ms needs at least 2 developer (what if one quits ) working on each service ? You need as many host servers as you have services
2 You need to tack the flow of calls across call stack services . How about transaction ?
3 Code duplication is sure shot, data redundancy too .
4 you need backup plans , alerts monitoring for all these instances
5 For long run more maintenance cost
At the end the benefit I found is instead of all services going down in Monolith only few will go down in Microservices
Less customer impact.
Yes definitely agreed with you. Continuous communication of developers is required. Microservices are costly and the complexity levels are comparatively high .
"Where is nothing micro about microservices" - loved it :))
Dude you're the best! I watched several system design tutorials. But yours is amazing♥️👌🏼
You are a very smart and intelligent kid Gaurav.. Keep shining..!!
A very clear and easy explanation of Microservices. Thanks a lot Gaurav
Made it this far starting from your first system design video in a single seating, I had never been this interested in studying before( hyperbole) and maybe I'll watch a few more : P. Thanks a lot!
Thanks Anjali!
Your videos are amazingly clear and concise. Thank you so much!
one of the best Microservice videos.
You've become one of my heroes in the programming world. Thank you so much!!
Best vid on microservices hands down
Gaurav , your enthusiasm and such detailed explanation with all cons and pros makes your videos amazing. I often go through them in my free time because not only it makes me think a lot but its fun too.
Thanks Vibhor!
I can give one example that why scaling factor is more important in micro services, lets say we have cart service and simple login service of ecommerce, now we know login service will have less traffic while cart service has lot of traffic during sales than logins, definitely if keep both of them in monolith, we can't scale them properly, clearly we can see that traffic on cart APIs will be much higher than normal APIs, so lets create different service for cart ;) and scale them differently by providing bigger and more servers to this micro service, that shows how important a micro services is :)
I am also thinking like you.
Let us consider we have 1000 cores CPU(100 servers with 10 cores load balanced) overall in monolith. At any given time at high load scenario, 80% resource is utilized by cart service and remaining 20% will be utilized by other services. If can track all the calls and the time taken, we can get to know the resource utilization by each feature.
All I am saying is, The requirement for scaling a monolith will come from higher load (We will not be sure about which feature is used more.) When we scale up, whatever the feature which was called a lot will be served easily without affecting others.
A very big advantage of microservices is that they are very easy to maintain, test and deploy. CI and CD are much more possible with a microservice architecture. You probably discussed that, and maybe I missed it. Good summary.
That's correct 😁
What CI and CD? I am a finance guy, trying to understand microservices for our office.
@@StackRadius Continuous Integration and Continuous Delivery.
"There's nothing micro about microservices" lol
Great video :)
Lots of good information. In practice I also see efforts around starting off with micro services and move some into bigger services when it makes sense
main advantage of microservice is: scalability. you have freedom to scale x microservice while y remains at same capacity. While in monolith, whole system scales. But one disadvantage of microservice is handling transactions. If you are having architecture like your transaction is spread across various microservices. its not good.
Please share your thought.
Transaction .nice point.I was thinking does it fit in e-commerce? What do you say ?
Monoliths kind of get a bad rap so I appreciate the more balanced answers here. If you're a small team the overhead of spinning up services can be a bigger deal and it can make less sense.
I believe decoupling is not something only found in microservices. Infact even if it's a single process a good programmer has to deside on what the components of the system are and decouple them with interfaces. One could even do independent deployability in a monolith by having the system components built in dll files instead of having them built statically. A new developer doesn't have to understand the entire code, just the component they are working on and the interface contract on how it interracts with the other components.
Per usual, Excellent, concise, accessible as heck!
Thank you for such contents to give good exposure of how things actually work. I have watching the whole playlist as I have an interview tomorrow. Hoping this works out for me.
Thank you!
Really informative. Your explanation was clear, simple, and well-organised. Thanks.
Thanks Gaurav for these excellent videos, really helped me a lot understanding some concepts. It would be really great if you could make a video where you code this stuff because theoretically everything makes sense but actually making a good system design out of a business requirement becomes a bit hard. So, it would be great to see how you design an actual system in terms of classes, DB etc. and how you decouple stuff. I know there are ton of videos out there but your style is really understandable for me. Thanks again.
+1
I have worked on both and the video quite summarize the experience one have. The "New Member" in a team point was quite right!
Amazing work! Thanks!
Thank you!
Like the point you highlighted about how if a microservice is only talking to one microservice, its a bad design in the first place.
wow, very crisp and clear . Thanks !
Very good video .watched many others same topic but you have presented really well and simple.. keep up good work..thx
A great intro talk about microservices: concise and clear. Thx.
Thank you!
You are awesome and very nice tutuor. One suggestion ,may be you can share more reference link , channel ,book etc with session for further study .
Worst thing to ask after this video would be what is stack overflow? 🤣🤣🤣🤣nice video hatss off ♥️♥️♥️
You had us the first minute, I'm not gonna lie.
Thanks for making system design videos. You're doing a wonderful job.
Thanks Kunal!
Thanks Gaurav, this is perfect!!! Keep making such content! 🤟
The awesome video was ...., thanks for explaining easy...
Thanks Gaurav. Excellent videos.
Excellent explanation and examples. Good work!
Thanks Gaurav. Your videos are always helpful and easy to understand.Cheers!
Thanks broo saved my life for my exam...
you have awsome charisma man!
thanks a lot for the great explamation!!!
Nice, well explained and engaging videos. The energy and positivity you show is great to watch. Great work. Keep it up!!
Super clear explanation. Thank you :)
You're welcome!
Your way of explaining things is so natural and easy to follow although I don't do lot of coding.
I guess you have a great future as fantastic teacher Gaurav, something really needed for our Indian education system where focus is mainly on clearing exam without knowing the concept + application of the technology.
Keep coding and keep teaching :-)
Thank you!
You are doing great work. They can be useful for placements
Microservices allows to be programing language poliglot, and data store poliglot, this is a great advantage to take the best of the programing language for each use case, and poliglot data store to get the best benefit of the different data store (rdbms. nosql, files, key value, etc) dependeing of the use case for the microservice.
Nice explanation bro..can you please provide a video of transaction management in microservices..
great videos and effort. subscribed to channel and been watching your videos to learn more about system designs in general. thanks for the content!
Concise and succinct. Great job
Thank you!
I watch your videos at 1.5x speed... And still understand each and every bit 😉
This is great, thank you for your work 😌
You can write points on the board, it can help.
Good idea. I forget that it at times :)
Excellent videos. Thanks Gaurav.
Very well explanation, thanks.
Hi Gaurav, Thank you so much for this Excellent knowledge. I would like to request you, Please make the videos on the Microservices design patterns. Thank you
thanks for the presentation and explanation.
You are welcome!
Good job gaurav...Keep it up....5 Star
You keep making vedio I will keep learning.... 💯 thanks
Great content as always. I think handling transactions also is a challenge in microservices, requiring eventual consistency, which I feel is hard.
Great video as always!
Very informative and just what I needed, thank you
Excellent guru
Microservices has all the associated complexities of the distributed system.
There is a higher chance of failure during communication between different services.
Difficult to manage a large number of services.
The developer needs to solve the problem, such as network latency and load balancing.
Complex testing over a distributed environment.
Yes, but the advantages of a microservice architecture outweighs the negatives, for a large team.
Your videos are great. I enjoy watching them and I think you're a good speaker.
Thank you!
Awesome explanation!! :)
Awesome video. Stack Overflow. Never heard of it. :D
Hahaha!
Awesome explanation!
Easily explained, thanks.
Hi Gaurav, Please add a video on what should be a developer's approach for using threading (extensive threading or moderate thraeding) and its consequences.
Interesting idea. I'll add this to my list 😁
Thank You :-)
Great video !!! I have been working with micro services .. I think is better than monoliths .. hello from Colombia 🇨🇴
Thanks Carlos!
The role of a Solution Architect is to actually design system in such a way that separate concerns should be designed as separate Microservices. The criteria of having a single consumer of a service or a small team to manage the application probably not a justification to ditch the Microservices design. Consider a small startup designs a Microservices app and invites contributors to enhance, integrate with other services, or simply the product is acquired by a big company to use with its other products. Furthermore, network calls among Microservices is not a major issue when deployed on same host, inter-process communication can be achieved through different strategy of developing Microservices clients.
In my humble opinion, Microservices should always be used, even a monolithic application should be developed with some provisions of Microservices.
Thanks for your efforts!!
😁
excellent explanation..not sure who (and why) is disliking the video! I just hope that, its a click by chance on the "dislike" button! Keep it up Gaurav! I am just loving these technical vidoes- as it helps me-who can't understand new things on the first go and searched for many easy-to-understand articles/videos! :-)
Thanks!
Well explained! Just one comment: in this video it is implied a little bit that a bad coupling among functions exists in monoliths. Actually unnecessary (bad) function coupling can exist in either microservices or monoliths. Choosing microservices doesn’t give us well decoupled functions automatically. Even worse, tangled functions among microservices make everything even harder than if same situation happens in monoliths. So no matter microservices or monoliths, be careful about dependencies. BTW, a lot of successful monoliths have good design with clean, decoupled modules/functions.
The video also mentioned separating concerns according to business responsibilities. So my comment is just an add-on to emphasize/clarify the point about possible complexities of coupling through libraries or runtime calls in microservices.
Thanks for posting this nice video!
Awesome observations! Thanks!
You had us in the first half, not gonna lie.
Perfect :-)
Awesome Gaurav.
very well explained! you own a new sub from this moment!
Thanks!