Microservices have made communication overhead a common problem. Applications need to communicate with many smaller services, having a higher amount of cross-service calls.
A service centralizes client requests to reduce the impact of communication overhead. It decomposes and makes the requests to downstream services, collects and stores responses as they arrive, aggregates them, and returns it to the caller as one response.
“A client might need to make multiple calls to various backend services to perform a single operation. This chattiness impacts performance and scale.”
Microservices have made communication overhead a common problem. Applications need to communicate with many smaller services, having a higher amount of cross-service calls.
A service centralizes client requests to reduce the impact of communication overhead. It decomposes and makes the requests to downstream services, collects and stores responses as they arrive, aggregates them, and returns them to the caller as one response.
Microsoft calls this pattern Gateway Aggregation. It can be implemented as a service with some business logic, that can cache responses and knows what to do when downstream services fail.
Calls to the API should work as one operation. The API of the aggregator should not expose details of the services behind it to the client. The aggregator can be a single point of failure, and if it’s not close enough to other services it can cause performance issues. The aggregator is responsible for handling retries, circuit breaking, cache, tracing, and logging.