Federation and Composite Schemas — GraphQL in Production

In larger organizations, one monolithic GraphQL server becomes a bottleneck. Federation (Apollo Federation v2, and the GraphQL Foundation's Composite Schemas work) lets each team own a subgraph; a router/gateway composes them into a supergraph and plans queries across services. Entities shared across subgraphs declare keys (@key(fields: "id")) and are extended by other subgraphs. Alternatives: schema stitching (older) or a single BFF graph over REST services.

Graph architectures

Criterion	Monolithic graph	Federation	BFF over REST
Team autonomy	Low	High	Medium
Operational complexity	Low	High (router, composition, registry)	Medium
Cross-service queries	In-process	Router query plans	BFF code
Best for	Small/medium orgs	Many teams, one graph	Few clients, many REST services

# orders subgraph
type Order @key(fields: "id") { id: ID!  status: OrderStatus!  customer: Customer! }
type Customer @key(fields: "id", resolvable: false) { id: ID! }

# customers subgraph
type Customer @key(fields: "id") { id: ID!  name: String!  email: String }

# The router fetches Order from 'orders', then resolves Customer fields from 'customers'
# using the entity key (_entities query).

Common pitfalls

Federating too early (operational overhead without many teams).
Entity resolution causing N+1 across services (batch _entities).
No composition checks in CI.

Key points

Subgraphs owned by teams
Router composes and plans
Composition checks in CI

Graph architectures

Common pitfalls

Key points

Practice questions