Microservices Integration Aggregators
In this article, I will talk about AGGREGATION design patterns developed for the need of transmitting data to the application layer.
Join the DZone community and get the full member experience.
Join For FreeWhile the usage area of Microservice architecture continues to expand; there stand the problems that need to be solved. Microservice design patterns also offer general, reusable solutions to these problems. In general, the applications are based on data, as a result, data consistency and management of data pose a challenge. In my previous article, I mentioned the SAGA design pattern to solve the problems that arise in terms of transaction management in Microservice architecture.
You may also like: Principles for Microservices Integration
In this article, I will talk about AGGREGATION design patterns developed for the need of transmitting data to the application layer. Since Microservices have their database(most of the time), aggregation patterns give an idea of what can be done to obtain composite data that more than one service can offer. It is not possible to use the old style table joins to be compatible with the encapsulation principle.
At this point, we can talk about two patterns:
API Composition
This pattern raises the need for a new composite service. For example, if we need the information about the customer's orders, we first query the Customer Microservice, and then we query the order Microservice to obtain the enriched data. It is essential to always have a maintenance cost in such a composite service.
The API COMPOSITION pattern solves below problems:
- Different clients may have different access privileges for the same data.
- Different clients may need different formats of the same data, creating the need to convert the data.
This pattern is implemented as API Gateway. API Gateway can be created programmatically or it is available ready to use from some vendors.
API Gateway is useful for not only in blending the data of multiple services but also in the following areas:
- It creates an entry point for Microservices and defines APIs.
- It can work like a proxy that will forward requests to the relevant service.
- It can convert between various protocols.
- Authentication/Authorization.
Aggregator
In Microservice architecture; since there is the principle of separating our large modules and our monolith applications into atomic parts that can work autonomously and independently, we may need queries that a few Microservices will come together and return results.
For this purpose, the aggregator Microservice can be written, and this aggregator Microservice collects data from multiple Microservices and runs the workflows that must be run, if any, and returns the results to the consumer. The reason we create the aggregate pattern especially by making composite service is that it is necessary to apply a business workflow while preparing the result data.
To Conclude
We use aggregates in case we need to apply business rules on the composite data gathered from multiple services; otherwise, API gateways are sufficient.
Further Reading
Opinions expressed by DZone contributors are their own.
Comments