Aggregator Design Patterns

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.

  1. 1. Scatter Gather Pattern
  2. 2. Chained Pattern
  3. 3. Branch Pattern

Explanation:
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,

  1. 1. A service to get Student Information
  2. 2. A service to get Marks & its related Information
  3. 3. A service to get Membership Information
  4. 4. 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.

  1. Solution 01: Scatter gather pattern:
    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.”
  2. Solution 02: Chained Pattern:
    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.

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 “X” is acting as the aggregator while it is branching out into 2 separate branches. The first branch contains an independent microservice (service “Y”) and second branch contains a chain of services, that has 2 microservices.

Benefits of using Aggregator Pattern

  1. i. Scalability of both the x-axis and z-axis
  2. ii. Easy to understand and implement
  3. iii. Microservices signature flexibility to internal services
  4. iv. Providing a single access point for microservices