Aggregator, Chain, and Branch patterns for microservices

In this article, we'll look at 3 patterns for communicating with microservices: Aggregator, chain, and Branch. And in what cases they should be used

Aggregator Pattern

The diagram above shows how it works. There is a single aggregator that collects the entire request from an external source, passes it to the appropriate microservice, and returns the result. The Aggregator node here can perform any necessary data manipulation, such as adding a timestamp to the request header or adding the requestor name for registration purposes, etc. 

Chain Pattern

The chain pattern has a single entry point - service A, and other services depend on service A and will be invoked along the chain.

Chain pattern is not the best solution to implement communication between microservices, because it makes microservices dependent on each other.

Chain pattern pros

The positive side of this pattern is that it is secure due to the single point of entry. A microservice that requires the highest degree of security can be left at the end of the chain, and thus access to it can be restricted.

Chain pattern Cons

The main cons of this pattern are that it is slow because requests go through multiple services. 

Branch pattern

The branch pattern is a hybrid of the aggregator pattern and chain pattern. In the above example, we can see that service A serves as an aggregator and is branched into two branches. One branch contains a single standalone service B, and the second branch contains a chain of services (Service C and D). This pattern will be useful when a large monolithic application needs to be split into an application with a microservice architecture.