API Gateway Aggregation
One entry point fans a request out to several services and merges results.
StarterWebPlatform
The gateway itself calls multiple backend services for a single client request and composes their responses, sparing the client from making several round trips or knowing about internal service boundaries.
When to use it
- A screen needs data from several microservices and round trips from the client would be slow
- You want to hide internal service topology from external clients
Trade-offs
- The gateway takes on aggregation logic and becomes a place business logic can creep into
- A slow downstream service can slow every aggregated response that includes it
Components used
Mobile AppAPI GatewayManaged App Service
How it works
- A single entry point receives the client request and fans it out to several backend services in parallel.
- Responses are merged into one payload, so the client makes one round trip instead of many.
- The gateway also centralises authentication, rate limiting and TLS termination.
Used in the wild
- Mobile clients where each additional round trip is expensive on high-latency networks.
- Composite views such as a dashboard assembling data from several owning services.
- Presenting a stable public API over an internally changing service topology.
Good to know
- The gateway becomes both a single point of failure and a deployment bottleneck if every team must change it to ship a feature — the specific problem BFFs split apart.
- Aggregation makes partial failure the norm. Returning a partial payload with an error field usually beats failing the whole request.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Blue-Green Deployment
Run two full production environments, switch traffic between them.
Canary Release
Send a small slice of traffic to the new version before a full rollout.