How does GraphQL federation work for microservices?

Question

IT Interview Practice · Accepted Answer

**Federation** lets many independently deployed services each own part of one graph, which a **gateway** composes into a single schema clients query. It is the modern replacement for **schema stitching**, where a gateway manually merged remote schemas — federation moves the merge rules into the subgraphs themselves.

## The architecture

```text
                 ┌────────────────────────┐
   Client ─────▶ │  Gateway / Router      │  (composed supergraph)
                 └───────┬────────┬───────┘
                         │        │  plans + fans out sub-queries
              ┌──────────▼──┐  ┌──▼──────────┐  ┌──────────────┐
              │ Users svc    │  │ Reviews svc │  │ Products svc │
              │  type User   │  │  extends    │  │  type Product│
              │  @key(id)    │  │  User/Prod  │  │  @key(id)    │
              └──────────────┘  └─────────────┘  └──────────────┘
```

Each service is a **subgraph**. A type is owned by one service and **extended** by others. The `@key` directive names the field(s) that identify an entity across services.

```graphql
# Users subgraph OWNS User
type User @key(fields: "id") {
  id: ID!
  name: String!
}

# Reviews subgraph EXTENDS User with fields it owns
type User @key(fields: "id") {
  id: ID! @external          # declared elsewhere; referenced here by key
  reviews: [Review!]!        # this subgraph contributes this field
}
```

When a query spans services, the gateway **plans** it: fetch the `User` from Users, then call the Reviews subgraph's **entity resolver** (`__resolveReference`) with `{ id }` to fill in `reviews`.

```js
// Reviews subgraph resolves the User reference the gateway hands it
const resolvers = {
  User: {
    __resolveReference: (ref, ctx) => ctx.reviewLoader.load(ref.id),
  },
};
```

## Federation vs stitching

Stitching centralizes merge logic in the gateway (brittle, gateway must know everyone). Federation **decentralizes** ownership: teams evolve their subgraph independently, and composition is verified in CI. The trade-off is a more complex gateway/router and cross-service query planning.

## Why it matters

At scale, one team cannot own a monolithic schema. Interviewers want to see you understand **entity ownership via `@key`, reference resolvers, and query planning** — and why federation beats stitching for organizational scaling, not just technical elegance.

The architecture

Federation vs stitching

Why it matters

Related questions