A platform team wants to add a gateway aggregation layer in front of every microservice so that all clients only ever talk to one aggregation endpoint. What are the costs of this approach, and in what situations is gateway aggregation the wrong tool?

## The concrete cost - **A new service.** The concrete cost of adding an aggregation gateway is that it's a new service someone has to build, deploy, scale, secure, and put on-call rotation behind, not a free architectural overlay. - **A coordination tax.** It also introduces a coordination tax: because the gateway's composition logic depends on the exact contract of every backend service it wraps, a schema or behavior change in any wrapped service can require a corresponding change in the aggregator, meaning backend teams can no longer change their service in isolation without checking the gateway. - **The ownership question.** In practice this ownership question, whose job is it to update the aggregator when a downstream contract changes, often ends up as everyone's problem and therefore no one's, which is a real organizational cost separate from any purely technical one. ## When it earns its keep, and when it does not - The pattern **earns its keep** specifically when the caller and the backend services are separated by a real latency gap that fan-out amortizes, most classically a mobile or geographically distant client talking to services that live close together in one datacenter. - When the caller and callee already **share a low-latency network**, for example two internal services calling each other within the same availability zone at single-digit-millisecond round trips, there's essentially no round-trip cost left to amortize. Wrapping that call in an aggregator adds a hop and an operational burden for a latency benefit that barely exists, which makes the pattern a poor fit there even though it would be an excellent fit for a mobile client hitting the same backend. ## The 'god gateway' misuse A second common misuse is the 'god gateway' anti-pattern: as more client types and more screens get added, the path of least resistance is often to keep extending one generic aggregation endpoint with more optional fields and more conditional branches selecting what to include for which caller. Over time this accretes into a sprawling, hard-to-reason-about composition layer that every team touching any client has to modify, and where one team's change risks regressing another team's response shape. The alternative, splitting into several purpose-built, per-client-team-owned Backend-For-Frontend services, keeps each aggregator simpler by giving it one clear owner and one clear set of client needs to serve, at the cost of some duplicated composition logic across them. ## Failure modes 1. **The aggregator as a bottleneck.** In production, the aggregator itself can become a bottleneck or single point of failure even when every individual backend service is healthy, if its own compute or connection resources aren't isolated per downstream or per client type: a burst of aggregate requests can saturate the gateway's own thread or connection pool well before any wrapped service runs out of capacity, making the gateway the binding constraint rather than the services it's fronting. 2. **Assuming aggregation solves data consistency.** A related, subtler failure is assuming aggregation solves data consistency across services; it does not. Aggregation composes read-time responses from independently-updated services, so it cannot guarantee that the pricing and inventory data merged into one response were consistent with each other at the same instant, which matters for anything requiring strong cross-service transactional guarantees. ## Where it shows up A real-world illustration of when to deliberately avoid aggregation is a team building a public API for third-party partners: partner use cases vary too widely to predict one useful aggregate shape ahead of time, so exposing granular, individually-composable resource endpoints and letting partners combine them as needed is usually the better fit, even though it reintroduces some chattiness the partner has to manage themselves. By contrast, a single first-party mobile app team that controls both the client and can dictate exactly what the backend needs to compose is the classic good fit, which is why the Backend-For-Frontend pattern, popularized by teams like SoundCloud and Netflix for exactly this reason, pairs one aggregator with one client team rather than one aggregator with every possible caller.