The aggregator design pattern is a pattern with a simple concept, but the applicability can be complex, depending on the scenario to which it applies. If we look at the real world, we will see that the aggregator design pattern is one of the most applicable and scalable patterns.

Obviously, there must be a need for the use of the aggregator design pattern. Let's look at our current microservices. We built a microservice to manipulate data from the UsersService and three other microservices to manipulate the data from the News microservice.

When we deal with our UsersService, we can say that, so far, this microservice is sufficient in itself. The business of a microservice is very simple and consists of registering and exposing user data; there is no business requirement that makes us think of modifying this microservice currently.

We can't say the same when it comes to the News microservices. One of the clients of our microservices is the portal main screen, and, for this client, it is interesting to show a mix of news together. To meet this requirement, we will use the aggregator design pattern.

The following diagram demonstrates exactly how our application should behave after applying the aggregator design pattern. The microservice responsible for the Users data follows with direct access through the load balancer/proxy, but microservices responsible for the News data have a new layer of interaction before the load balancer. The news layer works as an orchestrator:

Let's reflect a little more on our client's needs. The UI, which in this scenario is our client, needs information from three different types of news. To accomplish this task, the UI should know each route for each type of news, identify the best way to gather the data received, and obviously make at least three different requests for the backend. This is definitely a lot of responsibility for the web client. We will simply be creating an application that does not meet the real need of who is consuming our microservices.

To fix this type of problem, we will apply the aggregator design pattern. With this pattern, we created a microservice responsible for orchestrating the data for the client and provided a single access point for the information. Consequently, the number of requests by the UI can be reduced from at least three to only one request.

In this way, we are also applying a new concept where we have the Internal Services, which are the microservices that generate and provide data, and Public Facing Services, which are the microservices responsible for orchestrating the multiple data, Internal Services, and have more direct contact with the client layer.

To properly apply the aggregator design pattern, we have to follow certain steps:

1. Segregate the shared database
2. Modify the communication layer
3. Create the microservice data orchestrator

After these steps, we will be applying our new pattern. However, let's not just segregate data and create an orchestrator. We will do this by applying CQRS and event sourcing.

These two internal patterns are very pertinent to News applications. Remember that a renowned journalism portal needs a good reputation with readers, and event sourcing is perfect for auditing news content to avoid errata and possible public retractions.

CQRS is also very applicable in these microservices, precisely because the core of our business is to provide content in the same way while always preparing the latest content. This means that we have to be efficient at recording new data as well as showing the data recorded. With CQRS, we will provide just that by optimizing the writing layer separately from the reading data.