Design Patterns for Microservices - Part 01

“Art is the imposing of a pattern on experience.” — Alfred North Whitehead

After the previous article about Microservice Architecture. it is important to know to create scalable, maintainable services it is important to choose a design pattern based on the scenario.

Aggregator Pattern

When dealing with the Microservices to process a single request or complete a single functionality there might be a need for data from another service because each service has its own database or even consume the data through a service API.

If the developer chooses to retrieve data back from the service, process them, and then return there might be few issues. One of them is it breaks the “Do one thing” principle in microservice and leads to complexity of the system. And also can cause latency issues since API calls from one service to another service in a duplex way take time.

As a solution for this “Aggregator patterns” is used. There are three main aggregation patterns.

1. Scatter Gather / Parallel Aggregation Pattern

In parallel aggregation, the request comes parallelly for the different services where the data needs to retrieve from and then forward the appropriate response to the aggregator service. Aggregator service responsible for processing the data and send as one response.

2. Service Chaining Pattern

Sometimes service response has dependencies with other information, and for further aggregation of data of processing of data, it should have another set of data. In a scenario, like this the first request goes to the service and gets the data from it, and based on the response of that data it will move to the next service from the data got from the service one till the aggregation completes. The service chaining pattern is works in synchronous approach and requests pass one after another.

3. Branching Pattern

Services in the Microservices need to get data from different services which may be based on conditions or based on certain data sometimes the service needs to send the response or get the response may change at that time using branching pattern using the request can be forwarded to the appropriate service.

The Benefits of having this aggregation pattern is the adaptability, Sometimes the business requirement can change with time or there will be major version update can happen without backward compatibility either scenario there is a high chance of breaking the communication due to incompatibility, But if there is a middle aggregation service it can respond to the old version of the services till all services are successfully migrated to a new version or Based on the service consumer aggregation services can provide response how the other service expects it. And because of this intermediate service non of the service does not have to depend on any other main services. and have different implementations inside the services themselves.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store