Microservices Design Patterns | Microservices Architecture Patterns | Edureka Rewind

in today's market microservices have become the go-to solution to build any kind of application they're often known to solve various kind of challenges but this is not the end to the story as skilled professionals often face challenges while using this architecture itself so hello all this is sah on behalf of edu Rea and I welcome you to this session on microservices design patterns so in the session guys we'll discuss on the various design patterns that you can use while setting up an application using microservices so on that note let's take a look at the topics for today's session so the topics for today's session are as you can see on my screen we'll start this session by understanding why do we need design patterns and then we'll look into what exactly design patterns are after that I'll tell you what are microservices and then I'll talk about the principles behind microservices once you understand understand the principles behind microservices I'll finally end this session by talking about the microservices design patterns so I hope the agenda is clear to you guys all right so that's great so the first topic for today's session is why do we need design patterns so to understand this topic just consider the scenario where you have a team of developers let's say 30 developers right now you're given a project to basically build similar kind of applications as a team lead what will you do you'll just divide these three applications to a group of 10 10 10 developers right so the group one will have project one group two will have project two group three will have project three and all these three groups will have each of 10 developers right so now when this team of developers start developing the application they can follow different set of processes right so when I say process what I mean that is the way they're developing the application right so they can follow a particular part to develop an application right so let's say the group one is following process one group two is following process two and group three is following process three right now what can happen is that maybe process one works completely fine what I mean by that is that you know there's no error and then whatever errors are coming also there's no latency time there's no disadvantage in using that kind of process right but if you consider any other two processes let's say process two and process three it may happen that you know there could be few errors and maybe that's not the right way to build the application right so what could happen is that you know I'm not saying that you know process one is the only way to build an application Maybe they have a better way when compared to process two and process three right so as a team lead what you clearly understand is that you know your development team cannot build the application using process 2 and process three right so to ensure that all the teams follow the same process or maybe of same pattern you can use this concept of design patterns when the team's working on various projects use the same pattern to build similar applications right so basically they'll select a particular pattern and they'll build all the applications based on on that particular pattern itself on that particular pattern you'll make sure that you know you have the maximum advantages that you can get for your application right so that is the need of design patterns guys basically if you have to understand the need in a single line then you can just understand the fact that you know design patterns are used to make sure that you know your complete team is on the same plate and everybody is following the same process or maybe the same pattern to build the application right so I hope you've understood what is the need of design pattern right so now let's understand what exactly designed patterns are with my previous explanation you might have clearly understood that you know design patterns are basically a simple pattern based on which you build an application but yet if I have to Define design patterns for you then design patterns or software design patterns can be defined as a software template or a description to solve a problem that occurs in multiple instances while designing a software application or a software framework right so I hope you've understood what exactly design patterns are they're basically just a software template or a pattern or maybe a description to solve a particular problem and that particular problem is seen in multiple instances right so when you want to solve a problem which is in multiple instances you can go forward and choose the design patterns right so now that you know what are design patterns let's move forward with what are microservices now I'm explaining you what are microservices in short but yet if you want a detailed explanation of microservices and how you can build applications you can refer to our microservices playlist so on that note let's understand understand what are microservices well microservices or most commonly known as microservice architecture is an architectural style that structures an application as a collection of small autonomous Services model around us business domain so basically you can have a business domain and maybe all the functionalities and the features are divided into various microservices so in a microservice architecture each service is self-contained and implements a single business capability so for example let's say you have an e-commerce application now e-commerce application basically has customers orders and products right so basically a customer basically gives an order for a particular product now what you can do is you can build this application based on microservice architecture by dividing the customers into a specific service by putting the products into another service and the orders into the third service right so for this particular business domain or the e-commerce application you can have basically three services that is customers orders and products right so I hope that you've understood what microservices are basically as the term suggests microservices are basically small small Services communicating with each other to build a big application now to build microservices or to model microservices there are various principles behind it so next in the session let's look into the principles behind microservices so the principles behind microservices are as you can see in my screen it starts with independent and autonomous Services basically because you know each service is B independent of the other servers right that is because each service is either created for a domain or a business capability and each service has its own functionality right so that is the first principle coming to Second principle that is scalability so when you build microservices what you can basically do is for example let's say you have four services for a specific business domain then what you can do is you can scale a specific service individually without scaling the others right so let's say in the example that I took that is the e-commerce application we had free services right customers orders and product so if you want to scale the customer service individually you can definitely go forward and scale that particular service and you do not have to scale the orders of the product service similarly goes for the other services also coming to the third principle that is decentralization so decentralization is basically when you know you do not have a centralized architecture right what I mean by that is for a specific business domain when you build an application using microservices your complete control is not there for a specific service right so all the controls are basically divided into individual idual Services coming to resilient Services I would say microservices are resilient Services because you know let's say even if one service is completely down the complete application will not go down so in the e-commerce application let's say if the product service is down that doesn't mean that you know your application will stop working only that particular service is not working and the team will be working on that particular service to get back the service right so the only point that you have to understand is that you know even if a service goes down the complete application doesn't go down next we have is real-time load balancing so obviously when a client sends request it may happen that you know you have to retrieve data from multiple Services over there the load balancer comes into the picture and then it defines how much CPU or how much GPU should be used for a particular service to get the data and similarly how the client's request should be passed right so that's happening real time and in this kind of architecture the client doesn't have to wait for a really long time right so you get the outputs within seconds coming to availability I think the principle itself defines its uh functionality it's basically means that the services are available 24/7 and all these Services can be basically used as much as they want right coming to the next principle that is continuous delivery through devops integration well microservices is one such technology or maybe you know one such framework that you can understand which you can collaborate with devops to get continuous delivery of the output right so once you understand devops you'll understand how to deploy a service and how to get the outputs right after that we come to the next principle that is seamless API integration and continuous monitoring all the microservices have a specific API Gateway which is basically the entry point to the client's request right so whatever client's request has been sent it will be first sent to the API Gateway through which the request will be forwarded to the specific microservices and obviously these microservices are continuously monitored whether the response is sent back or not or maybe if the service is down or not coming to the next principle that is isolation from failures so when I say isolation from failures what I mean by that is you know all the services even if they're down or maybe if they have any specific errors that particular service will solve its own error and it won't disturb the complete application so let's say in the e-commerce application that we considered let's say if the product service is facing few errors then what will happen is only that particular service will be basically taken into account and the errors will be solved and those errors will not affect the application or maybe the other two Services coming to autoprovisioning autoprovisioning is basically the ability to deploy the information by itself right so basically the service will generate the information for the client's request automatically without anybody's help right so Guys these were the basic principles behind microservices that is independent and autonomous Services scalability decentralization resilient Services realtime load balancing availability continuous delivery through devops integration seamless API integration and continuous monitoring isolation from failures and autoprovisioning right so guys I hope you've understood the principles behind microservices right right so now once you start building microservices you often face few challenges because of which you have to start using design patterns so since this session is basically based on microservices we'll be looking into the microservices design patterns so let's get started with the first design pattern that is aggregator so when you hear the term aggregator what comes onto your mind in Computing World aggregator refers to a website or a program that collects related items of data and displays them right so even in microservices pattern aggregator is basically a web page and invokes various services to get the required information or achieve the required functionality apart from this when you basically build a microservices architecture maybe a microservices application by breaking down the monolithic application or the monolithic architecture the source of output gets divided right so when I say monolithic architecture you can just consider it to be a one big block right so when you break that one big block into small small Services the source of output also gets divided right so this pattern basically proves to be beneficial when you need an output by combining data from multiple services so if you consider a client sending a request and maybe if you need data from two Services then aggregator is a design pattern that you should go for right now how do you think that happens so what basically happens is that you know let's say we have two Services when a client sends request and maybe that you know we want the data from both these services so what will happen is that both these services will be having their own database so with the help of aggregated design pattern what will happen is that you know each transaction will have a unique ID So based on that particular ID the request will be sent and all the data will be collected from The Individual Services and the required business logic will be finally applied after that what will happen is that you know whatever data is collected it will be published to the rest endpoint and later on what will happen is that the data will be consumed by the respective Services which require that data right so it could be a specific consumer or maybe a user or maybe a group of users or so on right so if you have to understand aggregator pattern guys it's really simple so aggregator pattern is basically a web page which invokes various services to get required information so whenever a client requires a specific information from two or three services you can go forward with this aggregated design pattern also before I move forward to the next design pattern I would like to mention over here is that you know aggregate a pattern is basically based on the drive principle so what happens is that you know based on this principle you can abstract the logic that is the business logic into composite micros services and aggregate that particular business logic into one service right so let's say you have a business logic right so that particular business logic what you can do is maybe you can put that particular business logic into two to three microservices later on what you can do is you can aggregate that business logic into one specific service right so for example if you consider two Services service a and service B then you can individually scale the services simultaneously by providing the data to the composite service right so that was about the aggregated design patterns guys let's move forward with the next design pattern that is API Gateway now microservices are built in such a way that you know each service has its own functionality but when an application is broken down into small autonomous Services there could be a few problems that a developer might face now the problems could be how can I request information from multiple microservices how can different uis require different data to respond for the same backend database service or how to transform data according to a consumer requirement from reusable mic services or how to handle multiple protocol requests right so Guys these are basically few problems that all the developers face well if you wish to solve these problems then I would say the solution to these kind of problems could be the API Gateway design pattern so the API Gateway design patterns addresses not only the concerns that I mentioned right now but also it solves many other problems this particular pattern can be considered as a proxy service to rout a request to their concerned micros service so basically as I mentioned before for API Gateway is the entry point to the client's request also being a variation of the aggregator service it can send a request to multiple services and similarly aggregate the result back to the composite service or the consumer service right so the API Gateway as I mentioned is basically at the entry point for all the microservices and can create fine graen apis for different types of clients right so maybe you have a client sending a specific request or maybe the client B sends a different kind of request right so with the help of this particular pattern you can create fine grain apis for all different kinds of clients and for the request also since developers are always concerned about you know how to handle multiple protocol requests API gateways can convert the protocol request from one type to another type similarly it can also offload the authentication responsibility of a specific microservice so once the client sends the request these requests are basically passed to the API Gateway which acts as an entry point to forward the client's request to the appropriate Microsoft Services then with the help of the loadad balancer the load of the request is handled and the requests are sent to the respective Services right so microservices also use the service discovery which basically acts as a guide to find the root of communication between each of them so when I say each of them I mean two microservices so microservices can communicate with each other via stateless server that is either by HTTP request or message bus right so with the help of API Gateway pattern guys a client's request is basically forwarded to the correct micros service and even if there are different kinds of clients using different uis or maybe different protocols and they want the data from the same backend service then API Gateway design pattern is your solution right so I hope that you've understood what is API Gateway design pattern now let's move forward with the next design pattern that is chain or chain of responsibility so the chain or chain of responsibility design pattern basically produces a single output which is a combination of the multiple chained outputs I hope that is clear to you guys right so as the name suggests in this particular design pattern what happens is that the client request is passed to let's say service a and then the request is passed to service B and then the request is passed to service C similarly the response is first collected from service C to service B and then from service B to service a and finally it goes to the client right so as the name suggest guys the chain or the chain of responsibility design patterns produces a single output which is a combination of the multiple chained outputs so for example if you have three services lined up in a chain then the request from client is first received by service a and then this service communicates with the next service service B and collects the required data finally the second service communicates with the third service to generate the considered output and what happens is that all these Services response is sent again from service C to service B service B to service a and finally to the client right so all these services use synchronous HTTP request or response for messaging also under the the request passes through all the services and the respective responses are generated the client does not get any output right so guys this is kind of a disadvantage in this particular design pattern because you know let's say you know you have 20 Services lined up and maybe the client request is a very big request right so until all the data is collected from all these particular services and then the response back is generated the client does not see any output right so it's always recommended not to make any long chain as the client has to wait until the chain is complete deleted right but before I move forward to the design pattern one more important aspect which you need to understand is basically that you know the request from service a to service B may look completely different from how the request is from service B to service C similarly is the case for response maybe the response from service C to service B may be completely different from service B to service a right so that's what you have to understand about the chain of responsibility or change design pattern guys now let's move forward with the next design pattern that is a asynchronous messaging design pattern so what do you understand by this term asynchronous messaging obviously the messaging pattern between microservices is not synchronous right so in the previous design pattern we had discussed synchronous messaging right so that was because you know service a communicates with service B and B to C right but in asynchronous messaging pattern it's not necessary that you know all the services communicate like you know Service A to B or B to C maybe service a can directly communicate service C and maybe service C can communicate with service B or maybe service B does not communicate at all right and service B communicates with service a right so basically what you have to understand is that you know since the client Waits a long time without any output and synchronous messaging and maybe you do not want the client to wait for a long time this is where basically you use the asynchronous messaging design pattern right so in this particular pattern what happens is that all the services communicate with each other but maybe they do not have to communicate with each other sequentially so if you considered free services as I just mentioned before service a b and c the request from client can be directly sent to service C and service B simultaneously when I say simultaneously what happens is that you know the single request from client is sent to both the services together that is servy and service B so then what will happen is that you know these requests will be in a queue so when I say Q you can understand that you is basically a line of requests so when a client request is simultaneously sent to two Services you basically build a queue and apart from that what you also have to understand is that you know let's say the service a sends a request to service C it's not necessary that you know service C sends back a response to service a itself maybe it can follow a different path and then finally a response can be sent right so the path is not defined and it is not done sequentially in asynchronous messaging pattern right so guys that was about asynchronous messaging design pattern next let's move forward with the next design pattern that is database design pattern or shared data design pattern now for every application there's obviously a humongous amount of data present right so when we break down an application from its monolithic architecture to microservices it's very important to know that you know each microservice has a sufficient amount of data to process a request right so I hope that point is clear to you when we break down the monolithic application into small small Services we need to make sure that you know each microservice has sufficient amount of data to process the client's request so either the system can have the database for each service or it can have shared database per service right so when I say database per service what I mean that is you know each microservice in the system will have a specific database for themselves and share database for service is basically when two or three microservices together share a specific database right now you can use the database per service or share database per service to solve various problems so the problems could be basically the duplication of data and consistency different Services have different kinds of storage requirements so the problems could be basically the duplication of data and inconsistency different Services have different kinds of storage requirements few business transactions can query the data with multiple services and denormalization of data is not easy right so to solve these kind of problems basically you can use the database for service or the share database for service right so if you have to solve let's say you know the duplication of data and inconsistency and maybe different Services have different kinds of storage requirements or maybe a few business transactions can query the data with multiple Services I think you should go for database per Service as it will then be accessed by microservices API itself right so each microservice will have its own database ID which thereafter prevents the other services in the system to use that particular database right so only that particular microservice can access a specific database present for that particular microservice itself right so apart from this to solve the issue of denormalization you can go forward with the shared databases for service to align more than one database for each microservice so what will happen is that this will help you gather data for the monolithic applications which are broken down into microservices but you have to keep in mind that you know you have to limit these databases to two or three microservices else scaling these services will be a big problem right so guys that was about the database design patterns let's move forward with the next design pattern that is the event sourcing design pattern so the event sourcing design pattern basically creates events regarding the changes in the application state so these events are stored as a sequence of events to help the developers track which change was made when and by whom right so with the help of this you can always adjust the application state to cope up with the past changes and also you can query these events for any data change and simultaneously publish this events from the event store right so once the events are published you can see the changes of the application State on the presentation layer right so that was about event sourcing design pattern guys event sourcing design pattern is basically used to create events regarding the changes in the application state right you've done a specific change and maybe you want to go back to the previous change that You' have done you can always use this particular kind of pattern to go back and see what changes was made and when and by whom right so that was about event sourcing design pattern guys let's move forward with the next design pattern that is Branch pattern so what do you understand by Branch pattern obviously as the name suggests it's all about branches right so for a specific service you can have different branches right so the branch Microsoft service design pattern is basically a design pattern in which you can simultaneously process the request and response from two or more independent microservices so unlike the chain design pattern that I discussed before the request is not passed in a sequence but the request is passed to two or more mutually exclusive microservices chains right so this design pattern basically extends the aggregated design pattern and provides the flexibility to produce responses from multiple chains or a single chain right so for example if you consider an an e-commerce application then you may need to retrieve the data from multiple sources and this data could be a collaborated output from various Services right so you can use the branch pattern to retrieve the data from multiple sources right so the branch pattern is really simple to understand guys it's basically where you want to simultaneously process the request and the response from multiple microservices right so these could be either in a single chain or maybe it could be in multiple chains also but yes it's not necessary that you know the request or the response is done in a sequential manner so guys that was about the branch pattern now let's move forward with the next pattern that is command query responsibility segregator design pattern so command query responsibility segregator design pattern or more commonly known as cqrs is basically used when you want to query for a specific data right now what happens is that you know when you have microservices designed in the form of database per service or share database per service what happens is that you know you have limited access to database right so basically you cannot Implement a query as the data is limited to only a single database so in such scenario we basically use the cqrs pattern so according to this pattern what happens is that the application will be divided into two parts that is command and query so the command part will basically handle all the requests related to create update and delete while the query part will take care of the materialized views right so the materialized views are updated through a sequence of events which are created using the Event Source pattern that I just discussed before so in the cqrs pattern guys you basically divide the application into two parts that is the command and the query the command will take care of the requests related to create update and delete and the query part will basically take care of the materialized views right so with the help of this pattern you can make sure that you know you have good access to your databases and then the client's request is satisfied also you can make sure that you know your materialized views are updated through a sequence of events which are again created using the event sourcing design pattern so guys that was about the cqrs pattern now let's move forward with the next pattern that is circuit break pattern so the circuit break pattern as the name suggest is basically used to stop the process of request and response if a service is not working so for example let's say a client is sending request to retrieve data from multiple services but due to some issues one of the services down now there are mainly two problems which will see first the client will not have any knowledge about the service being down right so he or she will be continuously sending the request to that particular service the second problem that we see is basically the network resources will be exhausted with low performance and bad user experience as the client without knowing will be waiting for the response to come back right so to avoid such problems what you can do is you can go forward and use the circuit breakup design pattern so with the help of this design pattern the client will invoke a remote service via proxy the proxy will basically behave as a circuit barrier so whenever the number of failures cross the threshold number the circuit breaker trips for a particular time period and then all the attempts to invoke the remote service will fall in this timeout period right so once that timeout period is finished the circuit breaker will allow a limited number of test to pass through and only if those requests are succeeded the circuit breaker resumes back to the normal operation right so just in case if the test don't go through then there'll be a failure and the timeout period will begin again right so in this particular pattern what you have to understand is that is basically that you know when the number of failures cross a threshold number the circuit breaker will trip for a particular time period and then all the attempts to invoke that particular service will fall in that particular period right once that time period is done what will happen is that you know the circuit breaker will allow a limited number of test to pass through and only if the test succeed it will resume back to normal operation else it will show failure again and again the timeout period will begin again so with the help of circuit breaker pattern guys you can make sure that you know there's no exhaustion of the network resources with low performance per and always the user experience is kept at a good note right so that was about the circuit breaker design pattern guys now let's move forward with the last design pattern for today's session that is decomposition design pattern so microservices are basically developed with an idea on the developers mind to create small services with each having their own functionality but breaking an application into small autonomous units has to be done logically right so to decompose a small or a big application into small Services you can go forward and and use the decomposition patterns so with the help of this patterns either you can decompose an application based on the business capability or based on sub domains so for example if you consider an e-commerce application then you can have separate services for orders products and customers if you decompose by business capabilities but in the same scenario if you design the application by decomposing by subdomains then you can have services for each in every class so here in the example that I had considered before that is the e-commerce application if you consider a customer customer as a class then this class will be used in customer management customer support customer query and so on right so to decompose you can use the domain driven design through which the whole domain model is broken down into subdomains then each of these subdomains will have their own specific model or a scope that is basically the bounded context so now when a developer designs microservices he or she will Design those services around that particular scope or bounded context right either you can decompose microservices by business cap capabilities or by domains right now obviously these patterns might be sounding very feasible to you but yes these patterns are not feasible for a big monolithic application this is because of the fact that you know identifying subdomains or business capabilities is not an easy task for big applications right so the only way to decompose big monolithic applications is by following the wine pattern or the Strangler pattern so the wine pattern or the Strangler pattern is basically based on the analogy to a wine which BAS basically strangles a tree that it is wrapped around right so when this pattern is applied onto web application a call goes back and forth to each URI call and a service is broken down into different domains these domains are then hosted by separate Services right so according to the standler pattern two separate applications will live side by side in the same URI space and one domain will be taken into account at an instance of time So eventually what happens is that you know the new refractor application basically wraps around or you can say strangles or replaces the original application until you can shut down the monolithic application right so guys that was about this triangular pattern and I hope you've understood what is decomposition pattern right so guys with this note I hope you've understood the different microservices design patterns so if you have any other idea about the different design patterns that you know we can Implement in microservices please comment in the comment section until then that's all from my side today I hope you found this session informative and you learned the different design patterns for microservices so on that note I end this session today thank you and happy learning