Introduction – right to the problem
Imagine you have three microservices – Users, Products, Orders. Each exposes its own GraphQL endpoint. The client makes three separate requests and stitches the data itself. The result – high TTFB (up to 800 ms), duplicated logic on the frontend, and frequent errors when schemas change. Apollo Federation 2 solves this with a single entry point. The Router (written in Rust) accepts one query, builds an execution plan, and fetches data from subgraphs in parallel – the client never sees the internal structure. Our team has 5+ years of GraphQL experience and 30+ successful Federation projects. We guarantee a stable federated graph even when multiple subgraphs are deployed simultaneously. Contact us for an audit of your current architecture – we’ll identify bottlenecks and prepare a migration plan.
Without solving coordination and performance issues, you risk cascading requests, poor LCP, and dissatisfied users. Federation is not just a trendy pattern – it’s a way to encapsulate domain boundaries and enable fast iteration.
How GraphQL Federation solves the N+1 query problem
Without Federation, each subgraph may call another synchronously – causing a cascade of requests. Apollo Router automatically batches entity requests via the _entities query. Instead of 10 separate calls to the product service – one batch, reducing response time from 800 ms to 300 ms and cutting database load by 3x.
Integration complexity: each team owns its subgraph and publishes the schema via Rover CLI. The Router checks compatibility during composition – invalid changes are blocked. This eliminates up to 80% of coordination overhead.
Version synchronization: using a supergraph composition pipeline, you can canary‑deploy changes – the Router routes requests to different subgraph versions until stability is confirmed.
The Router automatically batches entity queries. When the client requests a list of orders with user and product data, the Router:
- Fetches orders from the Orders Subgraph.
- Extracts all
userIdandproductIdvalues. - Sends one
_entitiesquery in parallel to the Users and Products Subgraphs. - Merges results and returns them to the client.
To enable this, subgraphs implement __resolveReference – a function that returns an entity by its id. We always use DataLoader inside __resolveReference for internal batching – improving performance by 3x.
Why Apollo Federation over Schema Stitching?
| Criterion | Apollo Federation | Schema Stitching (graphql-tools) |
|---|---|---|
| Entity batching | Built-in (lazy) | Requires manual implementation |
| Composition | Automatic via Rover | One‑time schema merge |
| Distributed team support | Yes (delegation) | Limited |
| Router performance | High (Rust) | Medium (Node.js) |
If you have 2–3 microservices and low traffic, Schema Stitching is simpler. But as you scale, Federation brings architectural clarity and processes queries 3x faster.
How we do it: a case with three subgraphs
Typical stack: Apollo Server 4 + TypeScript for subgraphs, Apollo Router as gateway, Rover CLI for publishing and composition. DataLoader for batching, Jaeger for tracing.
Subgraph: Users Service
# users-service/schema.graphql
extend schema
@link(url: "https://specs.apollo.dev/federation/v2.3",
import: ["@key", "@shareable"])
type Query {
me: User
user(id: ID!): User
}
type User @key(fields: "id") {
id: ID!
name: String!
email: String!
createdAt: String!
}
// users-service/server.js
import { ApolloServer } from '@apollo/server'
import { buildSubgraphSchema } from '@apollo/subgraph'
import { gql } from 'graphql-tag'
const typeDefs = gql`...` // schema above
const resolvers = {
Query: {
me: (parent, args, context) => context.db.users.findById(context.userId),
user: (parent, { id }, context) => context.db.users.findById(id)
},
User: {
__resolveReference: async ({ id }, context) => {
return context.loaders.userById.load(id)
}
}
}
const server = new ApolloServer({
schema: buildSubgraphSchema({ typeDefs, resolvers })
})
Router configuration and CI/CD pipeline
# router.yaml
supergraph:
listen: 0.0.0.0:4000
subgraphs:
users:
routing_url: http://users-service:4001/graphql
products:
routing_url: http://products-service:4002/graphql
orders:
routing_url: http://orders-service:4003/graphql
headers:
all:
request:
- propagate:
matching: ^Authorization$
cors:
origins:
- https://your-frontend-app.com
limits:
max_depth: 15
max_aliases: 30
# Install and publish subgraph
curl -sSL https://rover.apollo.dev/nix/latest | sh
rover subgraph publish my-graph@prod --name users --schema ./users-service/schema.graphql --routing-url https://users.internal/graphql
Example federated query
# One query covering data from three services
query OrderDetail($orderId: ID!) {
order(id: $orderId) {
id
status
total
user { name email }
items {
quantity
price
product { name stock }
}
}
}
The Router builds a query plan: get order from orders-service → extract userId and productId → parallel fetch user from users-service and product[] from products-service → merge. Entity batching happens automatically – the Router sends a _entities query with a batch of representations.
Work process
| Stage | Time (days) | Outcome |
|---|---|---|
| Analysis | 1–2 | Schema audit, @key field identification |
| Design | 1 | Domain decomposition into subgraphs |
| Implementation | 3–4 | Write subgraphs with DataLoader |
| Router setup | 1 | YAML config, CORS, header propagation |
| CI/CD | 1 | Composition pipeline via Rover |
| Testing | 1 | Load testing with k6, query plan verification |
| Deployment | 0.5 | Canary rollout, Jaeger monitoring |
Typical mistakes during implementation
Checklist of frequent issues
- Incorrect
@key(fields:)– the Router cannot merge entities. - Missing DataLoader in
__resolveReference– each entity query hits the DB separately. - Header propagation not configured – authorization context is lost.
- Too deep nesting (
max_depth > 20) – heavy query plans. - Forgetting
@externalfor fields from other subgraphs – composition fails.
What is included
- Federated schema documentation and team guidelines.
- Access to Apollo Studio (or local Registry) for publishing.
- Team training on Rover CLI and DataLoader.
- First‑month support after launch (consulting, bug fixes).
Get a free project estimate – our engineers will analyze your schema in 2 hours and propose the optimal solution. Contact us for a consultation on federated graph architecture.
Timeline and pricing
Setting up Apollo Federation 2 with Router, composition pipeline, and 3–5 subgraphs takes 5–8 working days. The timeline may increase if migration from Schema Stitching or refactoring of legacy schemas is needed. Pricing is determined individually – contact us for a consultation on federated graph architecture.