A platform has grown to support three very different client types, a mobile app, a web dashboard, and third-party partner integrations, each needing different composed views over the same dozen backend microservices. What architectural choices exist for where aggregation logic should live, and what are the trade-offs between a per-client Backend-For-Frontend, one shared generic aggregator, and a query-based alternative like GraphQL?

## Three placements for the logic There are three concrete architectural placements for aggregation logic at this scale. 1. **A per-client Backend-For-Frontend** has each client team run its own thin aggregation service tailored to its own client, calling the same shared backend microservices as everyone else but composing responses shaped exactly for that client's screens. 2. **A single shared aggregator** has one team own a handful of generic composed endpoints reused across all client types. 3. **A GraphQL-style gateway** takes a different shape entirely: a schema describes the composable types and fields available, resolvers map each field to whichever backend service supplies it, and the client sends an ad hoc query selecting exactly the fields and nesting it needs, resolved server-side at request time. This last option is worth understanding as a generalized, declarative form of aggregation rather than an unrelated technology; it solves the same 'compose data from many services into one response' problem, just by shifting the shape decision from the gateway's endpoint design to the client's query. ## The choice is organizational, not only technical Which placement is right matters as much organizationally as technically. Aggregation exists to reduce client chattiness, but at this scale the question of where that composition logic lives, and who owns it, becomes just as important as the mechanics of the fan-out itself. Team topology tends to push toward per-client ownership, following the well-known observation that a system's architecture mirrors the communication structure of the organization that builds it, so that a client team can ship changes to its own aggregation surface without waiting on, or risking breaking, every other client. A shared gateway owned by no single client team tends to become a queue of pull requests from every client team instead. ## The trade-off profiles Each option has a distinct trade-off profile. | Placement | What it trades | |---|---| | **Per-client BFFs** | duplicate some composition logic across services in exchange for strong ownership and independent deploy cadence per client team | | **A single shared aggregator** | has lower short-term build cost, one thing to stand up instead of three, but accrues a growing coordination tax and blast radius as client needs diverge: a bug or a slow release train in the shared gateway affects every client at once, and its endpoint code accretes client-specific conditionals over time | | **GraphQL** | removes the need to add a new REST endpoint every time a client needs a new view, since clients simply ask for different fields against the same schema, but it shifts risk into the resolver layer: a naive resolver for a list of items that independently fetches one field per item can silently turn a single client query into hundreds of downstream calls, and the team now has to solve caching, query-depth limiting, and per-field authorization inside the query engine rather than at ordinary endpoint granularity | ## Failure modes 1. **The resolver-level N+1 problem.** A failure mode worth watching for at this level is a team adopting GraphQL purely to 'get away from REST aggregation' without addressing the resolver-level N+1 problem, which reproduces the exact chattiness aggregation was meant to solve, just relocated one layer down and hidden behind a single query that looks efficient from the client's side. The usual fix is batching or dataloader-style resolvers that collect all the per-item field requests for a given query and issue one batched downstream call instead of N separate ones. 2. **The shared aggregator that becomes a god-gateway.** A second, related failure mode is a shared aggregator that started clean and organically becomes the god-gateway anti-pattern as client count grows, at which point the practical fix is usually splitting it into per-client BFFs rather than continuing to layer on conditionals. ## Where it shows up - **Netflix and SoundCloud** are commonly cited as the originators of the BFF pattern, each building separate lightweight aggregation services per device or client team after a single shared API layer became an organizational bottleneck as their client surface diversified. - **GitHub and Shopify** are commonly cited large-scale GraphQL adopters, using a single schema-driven aggregation layer across many client types instead of REST BFFs, accepting resolver complexity in exchange for flexible, client-driven field selection across a very large and varied API surface. For the three-client scenario in this question, a reasonable principal-level recommendation is to start with per-client BFFs, since three clients is a small, manageable number with sharply diverging needs and ownership, and to reach for a schema-driven layer like GraphQL only once the number of distinct client views grows large enough that hand-maintaining per-client REST aggregation endpoints becomes the bigger cost.