Design Patterns for Microservices.
For the creation of contemporary applications, the microservices architecture has emerged as the best option. Microservices are renowned for resolving a number of issues that developers encountered when creating monolithic apps. However, there are a number of issues with this architecture. As a result, we must discover common patterns in these issues and devise reusable solutions. We now have a number of microservice design patterns as a result. As a result, I’ll be talking about two common Design Patterns in Microservices architecture in this article: Aggregator Pattern and Proxy Pattern.
Why Design Patterns Matter in Microservice Architecture?
Your application’s success or failure in a microservices architecture depends on your choice of design pattern. There are various design patterns accessible for microservices architecture, as I already explained. As a result, it is imperative that you make the appropriate decision because of the rewards. However, the entire system will be unstable and perform poorly if you don’t select the right design pattern for your situation.
01. Aggregator Pattern.
In Microservices Architecture, we split a large, complex application into small, autonomous, independently deployable services. Therefore, it’s necessary to think about how to collaborate the data returned by each service. In IT industry, aggregator refers to a website or program that collects related items of data and displays them. So, in microservices the Aggregator Design Pattern is a service that receives a request, then makes requests of multiple services, combines the results and responds to the initiating request.
In Aggregator Pattern, there are 3 ways to implement it within Microservices application.
- Scatter Gather Pattern
- Chained Pattern
- Branch Pattern
To explain this clearer, I will use an example as follows.
Assume you are a software engineer and your team has been assigned to develop a Microservices application for a University. However, they already have a monolithic system and what you have to do is convert this monolithic system into a microservice application. Imagine you have to develop 4 services as follows,
- A service to get Student Information
- A service to get Marks & its related Information
- A service to get Membership Information
- A service to get Achievements Information
Moreover, you have 2 consumers named as, “Grading System” and “Enrichment Program System” for these 4 services.
Problem :-
When it comes to implementing, your team might create 1 microservice for each system, since that’s how we supposed to implement a microservices application. But the thing is, what happen when “Grading System” wants student information and marks information, or “Enrichment Program System” wants membership and achievements information?
Solution :-
So, what you can do is, create a service to consume “student information” and “marks information” services and give the response to the consumer that required (Grading System). Basically what happen is, the newly created service will take the request from the “Grading System” and invoked those 2 services to aggregate their responses and send it back to the “Grading System.” In Aggregator Pattern there are 2 ways to implement this solution.
Solution 01: When you invoke the Grading System’s service, you can send a parallel call to the “Student Information” and “Marks Information” services, and get those responses to aggregate them as a single response. Now we can send this response back to the Grading System (consumer). So, this is the first solution and it called as “Scatter gather pattern.”
Solution 02: Assume the Marks Information service has a dependency on the Student Information service. In that case, you can’t use the Scatter Gather pattern. So, what we can do is invoke the “Student Information” service and get the Student Code along with the response, then pass to the “Marks Information” service. At last, get the marks and its related information and response back to the Grading System. So, this is the second solution and it called as “Chained Pattern.” However, this pattern is slower than the Scatter gather pattern.
01/1. Branching Pattern.
This microservices pattern is a mix of Aggregator and Chain design patterns, that allows simultaneous request or response from two or more independent microservices. As you already know, a microservice may need to get the data from multiple sources including other microservices. The Branching Pattern extends the Aggregator Pattern and provides the flexibility to produce responses from multiple chains or single chain. This design pattern comes handy when you need to convert a large monolithic application into a microservices application. To get things clearer, check the following diagram.
As you can see, the service “A” is acting as the aggregator while it is branching out into 2 separate branches. The first branch contains an independent microservice (service “B”) and second branch contains a chain of services, that has 2 microservices.
Benefits of using Aggregator Pattern,
- Scalability of both the x-axis and z-axis.
- Easy to understand and implement.
- Microservices signature flexibility to internal services.
- Providing a single access point for microservices.
02. Proxy Design Pattern.
Assume your client has a monolithic application and they decided to move it into microservices architecture. In that case your team might assigned to develop multiple services and deploy those continuously. While developing these microservices, there might be scenarios that some services require changes, like updating their functionalities. Updating a particular service can affect the other services, which consume that services. As a result, this might be led to a whole system break, and also it will hold the development of the application. However, we have a well-known solution for this type of situations: The Proxy Design Pattern.
What is Proxy Design Pattern?
This pattern is very similar to Aggregator Design Pattern and even consider as a variation of it. But in this case, no aggregation needs to happen on the client, but a different microservice may be invoked based upon the business need. The proxy pattern also able to scale independently on x axis and z axis as Aggregator Pattern. So, the main idea behind this pattern is, not to expose each microservice to their consumers and instead it should go through an interface.
Let’s take an example to understand how the Proxy pattern work in a microservices application. Assume there is an employee management system, and it has a service to get the leave information of employees. Also, this leave-service work with several other services and they already consuming it. However, you decide to deploy a new version of this leave-service with few changes. As a result of those changes, the consumers of this leave-service going to break, since they didn’t get the required update to work with the new leave-service version. This is where the Proxy Pattern comes in handy. To overcome the above situation with the Proxy Pattern, we have to create a Proxy service for that particular service (leave-service). Therefore, all the consumers have to communicate the leave-service through this Proxy Service. As a result, developers don’t need to change anything in consumer side. Because, if a consumer need to communicate with the old version of the leave-service, the proxy will direct the request to the old version, and if a consumer need to communicate with the newer version, the proxy will direct the request to the newer version of leave-service. However, if you don’t see any traffic for the older version of that service, you can decommission that particular version.
Semantic Versioning,
Versioning in a microservices application is very crucial part since it has many services with different versions. As we discussed above, we might need to deploy several versions of a same service. Therefore, the Semantic versioning comes really handy. Semantic versioning is a technique, that uses three non-negative integer values to identify the version types. In this technique the version format represent as “MAJOR.MINOR.PATCH.”
Service Discovery,
When using the Proxy pattern in your microservices application, it always better and recommended to use a Service Discovery Tool to search the services. Because, if the infrastructure gets changed in a microservices application, the host-name, and IP addresses can also be changed. But if you have a service discovery tool, the proxy can request it to find the correct version and its IP address, host-name, and etc. There are several popular tools such as, WSO2 Governance Registry, CONSUL, and ZooKeeper.
Reference :-
Krishantha Dinesh, Design patterns for Microservices — so you won’t Abuse it :), Jan 13, 2017,
