GraphQL Federation: Unifying Microservices into a Single Graph

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:

1. Fetches orders from the Orders Subgraph.
2. Extracts all userId and productId values.
3. Sends one _entities query in parallel to the Users and Products Subgraphs.
4. 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?

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

Typical mistakes during implementation

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 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.