I wrote about GraphQL last year and my position was: it solves real problems but adds real complexity, and most teams underestimate the operational cost. A year later, federation is the hot topic. Apollo is pushing it hard. Conference talks everywhere. Teams that just adopted GraphQL are now being told they need to federate.
I remain skeptical.
The problem federation solves
Federation exists because a single GraphQL server becomes a coordination bottleneck when multiple teams contribute to it. Schema changes need cross-team approval. A single deploy touches unrelated domains. One bad resolver takes down the whole API.
Federation fixes this by splitting the graph into subgraphs owned by different teams, composed behind a gateway. Each team deploys independently. The gateway stitches it together.
This is a real problem. At scale. With many teams. With a large, actively-evolving API surface.
The problem is: most teams aren’t there
Every team I’ve talked to this year that’s considering federation has fewer than 30 engineers. Most have fewer than 15. They don’t have a coordination bottleneck because they don’t have enough teams to create one.
What they have is a single GraphQL server that works. And someone read an Apollo blog post and now there’s a ticket to “federate the graph.”
Federation introduces a gateway with a query planner. It introduces composition – a build step where subgraph schemas are merged, and breaking changes are detected. It introduces entity resolution across subgraphs, which means you need to think about N+1 fetches at the gateway layer. It introduces distributed tracing across subgraph boundaries. It introduces versioning and compatibility rules for shared types.
All of that’s manageable. None of it’s free.
When it actually makes sense
You need federation when:
- Multiple teams (3+) independently contribute to the API
- Schema changes in one domain regularly block another team
- You need independent deployment of API segments
- The API surface is large enough that one team can’t own it
If those are true, federate. The organizational benefits are worth the operational cost.
If you’re a single team, or two teams that talk to each other daily, a monolithic GraphQL server with good module boundaries is simpler, faster to debug, and cheaper to operate. You don’t need a query planner. You need a code review.
The N+1 problem gets worse
GraphQL already has an N+1 problem that DataLoader solves at the resolver level. Federation moves the N+1 problem up to the gateway. The query planner decides how to fetch entities across subgraphs, and it’s easy to end up with serial round-trips that destroy your latency.
You can mitigate this with batched entity resolution and careful schema design. But it’s another thing to get right, monitor, and debug. In a monolithic GraphQL server, a slow resolver is one function call away. In a federated graph, it’s a network hop through a query planner into a subgraph you might not own.
My recommendation
If you’re using GraphQL today and it’s working, keep it. Don’t federate because a blog post told you to.
If you’re genuinely hitting coordination problems – teams blocking each other on schema changes, deploys causing cross-domain risk, ownership unclear – then federation is a reasonable solution. Invest in the composition pipeline, the observability, and the entity resolution patterns. Treat it as a significant infrastructure investment.
And if you’re still deciding whether to adopt GraphQL at all, I’ll repeat what I said last year: REST with good API design and versioning covers most use cases. GraphQL is worth it when you have diverse clients with genuinely different data needs. Federation is worth it on top of that only when you have the team scale to justify the complexity.
Most teams should stop adding layers and start shipping features.