A single GraphQL schema owned by one team becomes a bottleneck the moment several teams need to add to it. Every change queues behind a review from the schema owners, and the owners become a service organization for everyone else. Federation exists to remove that bottleneck: each team defines its own subgraph, and a router composes them into one graph clients see as a single API.
That is an organizational solution wearing technical clothing, which is worth saying plainly because it determines whether you need it.
What changed in 2026
- The specification ecosystem broadened. Multiple router implementations and open specifications reduced the degree to which federation meant one vendor's product.
- Composition checks became standard in continuous integration. Validating that subgraph changes compose cleanly before merge moved from advanced practice to baseline.
- Performance tooling improved. Tracing across the router and into subgraphs got better, which made the fan-out problems visible rather than mysterious.
- The simpler alternatives gained respect. For smaller organizations, a single schema or a plain gateway increasingly got recommended over federation's operational weight.
What federation adds and costs
|
Single schema |
Federation |
| Schema ownership |
One team |
Distributed by domain |
| Deployment coupling |
Teams coordinate releases |
Subgraphs deploy independently |
| Breaking change detection |
Code review |
Automated composition checks |
| Operational components |
Server |
Router plus every subgraph |
| Debugging a slow query |
One service |
Router plus fan-out across services |
| Right for |
One team, one backend |
Multiple teams owning distinct domains |
The debugging row is the honest cost. A slow query in a single-schema setup is one service to profile. In a federated graph it is a router decision plus an unknown number of subgraph calls, and understanding it requires distributed tracing configured across every participant — the setup covered in OpenTelemetry setup guide.
The performance trap
Entity resolution is where federated graphs go wrong. When a query spans subgraphs, the router fetches entities from one and then resolves referenced fields from another. If that second step happens per entity rather than in a batch, a query returning fifty items produces fifty downstream calls.
Federation's design anticipates this and provides batched entity resolution, but it only works if subgraphs implement their reference resolvers to accept batches. A subgraph author who implements the single-entity version — which is simpler and works correctly — creates a performance problem visible only under load and only in queries that cross into their subgraph.
The mitigation is convention plus measurement: require batched resolvers in subgraph review, and trace queries across boundaries so fan-out is visible. This is the same class of problem as an ordinary database N-plus-one, distributed across a network, which makes it considerably more expensive per occurrence.
Common mistakes
- Adopting it with one team. The organizational problem it solves does not exist yet.
- Unbatched entity resolvers. Correct, simple, and quietly catastrophic under load.
- No composition checks in CI. Breaking changes reach the router instead of failing the build.
- Treating the router as stateless and free. It is a critical service needing capacity planning and monitoring like any other.
- Federating across genuinely unrelated domains. If subgraphs share no entities, you have several APIs behind one endpoint, not a graph.
FAQ
Is federation the only way to split a GraphQL schema?
No. Schema stitching and simple gateway composition are lighter alternatives. Federation adds entity resolution across subgraphs, which is what you are paying the complexity for.
Can subgraphs be written in different languages?
Yes, that is a significant part of the appeal. Any language with a compliant subgraph implementation can participate.
How do we handle authorization across subgraphs?
Consistently, or it becomes the main source of bugs. Decide early whether authorization lives in the router, in each subgraph, or both, and document it.
Is GraphQL still the right choice at all?
For clients with varied data needs, often yes. For simple resource-oriented APIs, REST with good conventions is less machinery — the error design in API error design applies either way.
Where to go next
For tracing across services, read OpenTelemetry setup guide. For API design fundamentals, API error design and API versioning strategies.