Most teams adopting GraphQL federation have no business doing so. There. I said it.
I’ve spent the last few months watching startups with fewer than 20 engineers spin up Apollo Gateway, split their schema across three services, and then wonder why deployments take twice as long and debugging is a nightmare. The answer is simple: you built infrastructure for a problem you don’t have.
The conference talk pipeline
Here’s what keeps happening. An engineer goes to a conference. Sees a talk from Airbnb or Netflix about how federation solved their scaling problems across 200 engineers and 40 services. Goes back to work on Monday and pitches it to the team. “We should do this. It’s the future of GraphQL.”
No. Airbnb has Airbnb problems. You have a monolith with six developers and a product manager who keeps changing the roadmap. Those are different problems.
Federation solves exactly one thing: schema ownership across many autonomous teams that need to ship independently without stepping on each other. If you can walk over to the person who owns the other part of your schema and talk to them, you probably don’t need federation. You need a conversation.
When REST is just fine
I run into this constantly. Teams that had perfectly functional REST APIs, decided GraphQL was the move (fine, sometimes it’s), and then immediately jumped to federation because… why not go all the way?
Here’s when REST is completely adequate:
- Your API consumers are mostly your own frontend team
- You have fewer than ~30 endpoints
- Your data model isn’t deeply nested or relational from the client’s perspective
- You’re not doing a lot of cross-entity queries in a single request
I’ve built systems at Dropbyke and the fintech startup. Both had phases where REST was the right call. Both had phases where GraphQL made sense. Neither needed federation. Not even close.
The actual cost nobody talks about
Let me walk you through what federation actually adds to your stack:
A gateway service. That’s a new thing to deploy, monitor, scale, and debug. It’s in the critical path of every single API request. When it goes down, everything goes down. Hope you enjoy being on-call for that.
Schema composition. Your CI pipeline now needs to compose schemas from multiple services and validate they don’t conflict. That’s a new failure mode in deployment. Fun.
Query planning. The gateway has to figure out which services to call for each query and in what order. This is non-trivial. It gets wrong sometimes. The debugging experience is poor.
Cross-service data loading. __resolveReference looks clean in a conference slide. In practice, it’s a hidden N+1 problem that you’ll discover in production at 2am. You’ll need DataLoader in every service, and you’ll need to think carefully about batching across service boundaries.
Contract management. Every @key, @external, @requires directive is a contract between teams. Breaking changes in one service can silently break another. Schema registries help but add yet another moving part.
All of this for what? So two teams don’t have to coordinate a PR? Send a Slack message. Do a code review. It’s not that hard.
When federation actually makes sense
I’m not saying federation is useless. It solves a real problem. But the problem is narrow:
- You have 50+ engineers working on the same API surface
- Multiple teams genuinely own different business domains
- Schema changes are blocked for weeks because of coordination overhead
- You’ve already tried a monolithic GraphQL server and hit real, measurable bottlenecks
If all four of those are true, yes, look at federation. If you’re checking two or fewer, don’t.
What I’d do instead
For most teams I talk to, here’s the boring answer:
One GraphQL server. Modularize it well. Split your schema into files by domain. Use a good folder structure. Code review changes to shared types. That’s it.
If your schema file is getting unwieldy, that’s a code organization problem, not an infrastructure problem. You don’t solve messy code with more services. You solve it with better code.
If you genuinely need multiple services behind a single API, look at schema stitching first. It’s simpler, has fewer moving parts, and you can always migrate to federation later if you outgrow it. You almost certainly won’t outgrow it.
The real lesson
Every architecture decision should start with “what’s the simplest thing that works?” and only get more complex when you have evidence – not conference-talk vibes – that the simple thing is failing.
Federation is a tool for large organizations with specific scaling challenges. It’s not a best practice. It’s not a default choice. It’s an escape hatch for when simpler approaches have demonstrably failed.
If you’re reading this and you’ve already adopted federation with a small team: it’s not too late to back out. The migration back to a single schema is way easier than the migration forward was. I promise the relief will be immediate.