Aggregator Microservice Design Pattern 🧮

Irushinie Muthunayake
Nerd For Tech
Published in
6 min readJun 9, 2021

(Design Patterns— Part- 01)

📍 Before going into the design patterns, first, we should understand the principles behind them. So below are some principles which were used to design Microservices.

▪️ Availability

▪️ Resilient Services

▪️ Isolation from Failures

▪️ Scalability and Auto Provisioning

▪️ Autonomous Services

▪️ Independent

Why we need design patterns for microservices? 🧐

📍 The design patterns in Microservices are the software design patterns that produce autonomous services which are reusable (Because when the solutions to an issue are well known, then we can apply them to the same kind of issues in the future)and helps to overcome the common problems and challenges that we have to face when developing a system. So by using the corresponding design pattern to the appropriate issue, we can avoid those problems as well as the challenges.

Design patterns for microservices

📍 There are a set of design patterns that can be categorized such as communication, observability, decomposition, User interface, database, security, deployment, testing, and so on. So among them, Aggregator, Circuit Breaker, Asynchronous Messaging, Event Sourcing, Command Query Responsibility Segregator, API Gateway, and Decomposition are some design patterns we found in microservices.

Ref: Richardson 2017

▪️ It’s really difficult to say that one design pattern is better than another pattern. And it depends on the context and the requirements of the application which we are developing. However, in this article, I'm going to cover the Aggregator Microservice Design Pattern 😁

Aggregator Microservice Design Pattern

📍 The aggregator is a simple web page that invokes multiple services and aggregates the needed information that comes from different services and then sends it back to the consumer as the final response.

This pattern has 3 different aggregator patterns as below.

Example:

▪️ Assume we have two services as X and Y, and each of these services has its own DB. And the aggregator receives a request from a client and therefore it will collect the information from each service X and service Y. And then it will merge the collected data accordingly and send it back to the consumer as the response. (The below diagram will show how this works)

Let’s try to understand the Scatter gather pattern, Chaining pattern, and Branching pattern by using the below example.

Example:

▪️ Assume you have been asked to implement a microservice platform for an Information Technology company.

▪️ Now you came up with the below design ➙

Service ➞ service to get a person information

Service ➞ service to get a leave information

Service ➞ service to get an appraisal information

Service ➞ service to get an allocation information

And you have 2 consumers as Attendance Management System and Project Management System.

This particular Information Technology company has a monolithic system. So now it is your duty to convert this monolithic system to microservice architecture.

📍 Let’s think you are going to create:

one service to get personal information

one service to get leave information

one service to get appraisal information

one service to get allocation information, and now you can create 4 dockers for these 4 different services and deploy them accordingly.

But there’s a problem😭

▪️ You do not have any service to get Personal Information and Leave Information to the Attendance Management and get Personal Information and Allocation Information to the Project Management.

The solution for this is 🤓

◼️ You can create one service to consume those 2 microservices and give the response back to the consumer. So accordingly this service will take the request from the consumer and invoke Personal Information and Leave Information and aggregate those responses and send it back to the consumer.

▪️ We can use Parallel aggregation/Scatter gather pattern as an option for this as below:

How?

▪️ When you invoke the Attendance service, you can send the parallel call to the Personal information service and Leave Information service. And get those responses and aggregate those as a single response and send it back to the consumer and this is called “Parallel aggregation/Scatter gather pattern”.

But there’s another problem☹️

▪ ️Assume that the Leave Information service has a dependency on the Personal Information service ☹️

The solution for this is 🤓

▪️ Invoke the Person Information service and get the employee code from there and pass that code along with other information into the Leave Information service and get the Leave Information and send the response back to the consumer. So this is called the “ Chained pattern”.

✨Chained pattern

📍 As we discussed in the previous example, the chained design pattern follows the chain structure. We do not use anything in between the service and consumer. In this design pattern, the consumer gets permission to communicate with the services directly. Here all the services are chained up in a way that the input of the next step is the output that was received by the other service.

Ref: https://www.tutorialspoint.com/microservice_architecture/microservice_architecture_composition_patterns.htm

Note: 📝 The Parallel aggregation is faster than the Chaining pattern.

Example:

▪️ Assume the Personal information service takes 5 milliseconds and Leave service takes another 5 milliseconds. If you use the Chaining pattern you will take 10 milliseconds. But if you use parallel aggregation, you can take both responses theoretically in 5 milliseconds. Thereby we can decide that The Parallel aggregation is faster than the Chaining pattern.

Note: 📝 :The main disadvantage of this chained design pattern is, the consumer will blocked till the whole process is finished. Therefore, the chain must be short and should not be too long (If not consumer will have to wait for a long time to get the response back and that’s bad.)

✨ Branching pattern

▪️ Branch microservice design pattern can be defined as a hybrid version of aggregator pattern and chain pattern. This pattern can also be used to invoke a single chain or different chains of services, according to the business requirements. Also, this can process the requests and responses which come from 2 or more independent microservices at the same time.

Example:

▪️ Assume you have a service like a user sends information as Employee ID and Branch code. So now you call the Person Information service and if the branch code is “Dev” it will call the Project allocation and if the branch is “Sale”, it will call the Sales Information service.

▪️ So according to the above example, Based on a factor, it made a decision and that calls as “Branching”.

Now, the business logic has changed as below:

Before: You had 4 services and you created an aggregation service to the Attendance Management system. Then you created the other aggregation service to the Project Management system. So the Project Management system will call Person Information Service and Allocation Information Service.

After changing the Business logic: Project Management changed their business logic to “check the leave information” before allocating to a new project.

▪ ️So you can develop this by creating a new service to invoke 3 services (Person Information, Leave Information, and Allocation Information). So accordingly now you are having 2 different services in your Project Management System.

▪️ You can deploy both into the production and ask consumers to migrate to the new version.

▪️ So after all the consumers migrated to the new version, you can shut down the previous one and keep only the new one live.

Advantages of the Aggregator Design Pattern

📍 Easy to understand.

📍 Easy to implement.

📍 Supplies a single access point for microservices.

📍 Decreases the communication overhead between the services and the clients.

--

--