Importance of Design Patterns for Microservice Architecture
Microservice is an other way of service oriented architecture(SOA). All are independent services, So we can add or remove services independently. It is valuable and practiced some architectural view. Refer my Introduction to Microservice article for more details. So, If the development team wants to adopt to Microservice Architecture, they should follow a set of best practices and use a set of reusable, battle-hardened design patterns. So, we are going to cover some important patterns in this article.
Aggregator Pattern
Aggregator is a basic web page which invokes multiple services to get the required information or achieve the required functionality.
It proves to be beneficial when you need an output by combining data from multiple services. So, if we have two services each having their own database, then an aggregator having a unique transaction ID, would collect the data from each individual microservice, apply the business logic and finally publish it as a REST endpoint. Later on, the data collected can be consumed by the respective services which require that collected data.
It talks about how we can aggregate the data from different services and then send the final response to the consumer. you can abstract the logic into a composite microservices and aggregate that particular business logic into one service. This can be applied in 3 different ways, such as parallel, chained, and branch pattern. Lets, understand one by one.
🧶 Parallel or Scatter Gather Pattern :-
Let’s say there are two services: Service A and B, then you can individually scale these services simultaneously by providing the data to the composite microservice.
🧶 Chained Pattern :-
This pattern produces a single output which is a combination of multiple chained outputs. Let’s say there are 3 services lined up in a chain, then, the request from the client is first received by Service A. Then, this service communicates with the next Service B and collects data. Finally, the second service communicates with the third service to generate the consolidated output. All these services use synchronous HTTP request or response for messaging. Even though the request passes through all the services and the respective responses are generated, the client doesn’t get any output. So, it is not recommended to make a long chain, as the client has to wait until the chain is completed.
The request from Service A to Service B may look different from Service B to Service C. Similarly the response from Service C to Service B may look completely different from Service B to Service A.
🧶 Branch Pattern :-
In this pattern you can simultaneously process the requests and responses from two or more independent microservices. The request is not passed here in a sequence like chained pattern, but the request is passed to two or more mutually exclusive microservices chains. It provides the flexibility to produce responses from multiple chains or single chain.
For example, if you consider an e-commerce application, then you may need to retrieve data from multiple sources and this data could be a collaborated output of data from various services. In this case, we have to use branch pattern.
Circuit Breaker Pattern
A Service normally calls to another service to retrieve data, in that situation there is a possible to downstream service to down. In that case, there is a chance to rise a problem, i.e if the request continuously going to the down service, network resources may be exhausted, and performance will be slow. So, to keep the service without dying or to keep in good health we need the circuit pattern.
Microservices are distributed system and multiple services, behave in different ways and maintained by multiple teams, so we have no idea how other services would break and we have the responsibility to keep the services alive. In that case, circuit breaker pattern is important.
Cascade failure :- When one service is connected to another and it is connected to another and go on. In that case, If one service fails, it will trigger other service to fail and go on.
The consumer should invoke a remote service through proxy which is likely to be electrical circuit breaker. When the number of consecutive requests crosses a threshold, and for the duration of a timeout period, all attempts to invoke the remote service will fail immediately. After the timeout expires the circuit breaker allows a limited number of test requests to pass through. If those requests succeed, the circuit breaker resumes normal operation. Otherwise, if there is a failure, the timeout period begins again.
Depends on your requirements you may need other design patterns as well. But I have covered some important patterns in Microservice Architecture.
I hope you got an idea of design patterns in microservice architecture.
Happy Learning.😊