AGGREGATOR DESIGN PATTERN IN MICROSERVICES
AGGREGATOR DESIGN PATTERN
=======================================
There are 3 different ways that you can implement Aggregator pattern.
Let us describe the Aggregator design pattern using a real world scenario.
Use case:
📝 Assume you are asked to implement a microservice platform for an IT company. They have different systems, but your responsibility is to implement microservices.
Remember: We need to go with a DDD (Domain Driven Design)
Just think you came up with a small design like this where there are 4 different services and consumers who use these services.
Furthermore, you have Attendance Management System and a Project Management System.
At present, the company has a monolithic system that has everything in built. They can login to the system, do project allocation, check leave and attendance system etc. Your responsibility is to convert this to Microservice platform.
How can you do this???
Someone can create one microservice for attendance system and another microservice for project management system. And another microservice can be created if you have something like Claim Management System. The fact that you need to focus on is to deal with a Domain Driven Design. There should be one service that does well.
Solution:
📍 Create first service ➜ To get personal information
📍 Create second service ➜ To get personal information
📍 Create third service ➜ To get appraisal information
📍 Create fourth service ➜ To get allocation information
✹ You do not have any service to get personal and leave information for the attendance system.
✹ There is no service where you get personal and allocation information for project management system. And that is fine. But why???
You have 4 different services. Those are micro-level services. These services will not do anything alone other than what it decides to do. This is fine because of the concept “ Do one thing and do it well” that is used in Microservices.
When you go with this kind of a pattern, you can create and deploy 4 or multiple dockers based on the demand since you have 4 different services.
Solution: Now you can create 1 service to consume those two microservices (personal information service & leave information service) and give response back to consumer. It will take the request from the consumer and invoke personal information service and leave information service, then aggregate responses and send back to the consumer.
How can you achieve the solution using;
Scatter Gather (Parallel) Aggregation Pattern
❉ You can send parallel calls to personal information service and leave information service. Then, get those responses, aggregate them as a single response and send back to consumer. This is called “Parallel Aggregation”.
Chaining Aggregation Pattern
❉ Just assume if your leave information service has a dependency from your personal information service.
Ex: The consumer sends Employee ID to you. Your leave system still does not know how to grab information from ID. May be the current version of leave system/database does not have ID. (Instead of that, it might contain something called “Employee Code”) But user will send you the user ID.
❉ Now, you can invoke personal information service and get Employee code along with other information from that. And then pass this code into leave information service and get leave information. Now you can send aggregated response back to consumer. This is called “Service Chaining”.
(You call one service, get response and call another service)
🔸 There is no requirement to get something from the first service, but one after the other.
If you go with Parallel Aggregation:
You can both (Personal & Leave) information in 10 ms (theoretically) which means you may be able to deliver your response within 15 ms.
If you go with Service Chaining Approach (one after the other):
First call will take 10 ms and second call too will take 10 ms. Altogether 20 ms. When you put your transformation time, it will take approximately 25 ms for the response.
- * This is not good! **
- This may be a better approach when you are migrating from monolithic applications to microservices platform since your backend may still run with some legacy platform.
🔔 Assume you have an encoding service where you take some response and push it into encoding service. It must be Service Chaining method because you have to get some response and you should send this to encode/decode/encryption service. In such kind of scenarios, you can apply aggregation pattern using service chaining.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Let us consider a use case.
Your project management service decides to check employee leave information before allocating a new project. Now, business logic has changed. Earlier Requirement was;
You have deployed in the production. You have 2 aggregate services in the production. They are for;
- Attendance System
- Project Management System
Currently;
Project Management System currently consumes 2 services.
- Personal information Service
- Allocation information Service
Now it is in the production. But their business requirement has changed eventually. They decide to check an employee’s leave behavior before allocating to a critical project.
Solution
💡 In such a scenario, you do not have to manipulate any existing services. You can create a new aggregation service that will invoke all 3 services.(Personal Information Service, Leave Information Service 7 Allocation Information Service) Aggregation services do not cost much. It does not need much performance as it just aggregates things without performing any transformation logic.
💡 You have 2 different services in your Project Management System. Now you can deploy both services in production. And you can ask consumers to migrate into this new version. And according to the scrum timeline/plans, consumers can slowly migrate into the new service that consumes all 3 backends. When you notice that all consumers have migrated from existing service, you can shutdown and keep the newer one alive.
Advantages of the Aggregator Pattern
💠 Reduces communication overheads among clients and services
💠 Easy to understand
💠 Easy to implement
💠 Can be developed fast
💠 Does not cost much
Disadvantages of the Aggregator Pattern
♨️ Latency of responses
♨️ Increased complexity
♨️ Availability issues
Instances where the Aggregator Pattern can be used
🔰 When there are Low Scale Needs
🔰 When business value functions are not critical
🔰 When a “combined” or monolithic service requires multiple teams to implement it
Considerations while using Aggregator Pattern
🔎 Single Logical Point of Failure
🔎 Install Circuit Breakers
🔎 Real Time Monitoring
🔎 Install Bulkheads
🔎 Latency
