The aggregator design pattern is very efficient for scalability, as we have seen throughout the chapter. However, this pattern can provide us with an anti-pattern if we aren't very careful with what we're doing. The anti-pattern that we can create is called a bottleneck. Let's understand how this anti-pattern can be created.

Our application that was a part of the News microservice was divided into Public Facing Services and Internal Services. With this design, to access the Internal Services, it is necessary to go through Public Facing Services, and it is here that the problem can occur.

The bottleneck happens whenever engineers misunderstand where the stress point of the application is and where it needs to be scaled. Consider the following scenario—it's the World Series and people want news on this end. Obviously, sports_news_service will receive a larger load access. The natural procedure is to create more instances of sports_news_service. However, even with a greater amount of resources for sport_news_service, the application does not scale. The following diagram shows exactly what is happening with the application:

The problem is just happening because we increased the resources of the Internal Service, but not the Public Facing Service. This means that sport_news_service does not respond properly because the path that needs to be taken to the microservice is blocked or does not have adequate performance. The problem can be even more serious, because, as the Public Facing Service is serving more than one microservice, other parts of the application are also going through the same problem of slowness. What has been created with this scale of disaster using the aggregator design patterns was a bottleneck.

As a solution to this problem, we must scale the application proportionally, as shown in the following diagram: