Apollo Router can add under 10ms of latency while handling federated graphs at scale. See how Federation v2 composes, plans, and evolves safely. Read now.
What Federation v2 Actually Composes
GraphQL Federation lets many independently owned services contribute to a single graph that clients query as though it were one API. Federation v2 refines how those pieces come together: each subgraph declares the types it owns and the fields it can resolve, and a composition step merges them into a supergraph schema. The result is a distributed graph — a supergraph — where teams ship their own subgraphs on their own timelines without coordinating a monolithic deploy.
The important shift is that composition is a first-class, verifiable operation rather than a hopeful merge. When two subgraphs describe overlapping types, Federation v2 resolves ownership explicitly: one subgraph is the source of truth for a key, others extend it with additional fields. Composition either produces a valid supergraph or fails with a specific reason, so schema conflicts surface at build time instead of as runtime surprises.
The Router and the Sub-10ms Budget
The Apollo Router sits in front of the subgraphs. It receives a client query against the supergraph, decides which subgraphs must be called and in what order, fans out the requests, and stitches the responses back into the shape the client asked for. The claim worth taking seriously is that this coordination can add under 10ms of latency even as the graph scales — meaning the router's own planning and merging work stays small relative to the network and resolver time you were already paying.
That budget matters because the router is on the hot path of every request. If orchestration were expensive, federation would tax every query. Keeping the overhead low is what makes splitting one graph across many services a practical default rather than a tradeoff you constantly second-guess.
How Query Planning Works
When a request arrives, the router builds a query plan: a sequence of subgraph fetches that satisfies the query while respecting type ownership and entity keys. If a client asks for a product plus its reviews, and those live in different subgraphs, the plan fetches the product, carries its key to the reviews subgraph, and joins the results. The client never sees any of this — it wrote one query and received one response.
Good planning is what keeps federation efficient. A few properties do most of the work:
- Parallelizing subgraph fetches that don't depend on each other, rather than calling them in sequence.
- Using entity keys to resolve references across subgraph boundaries without over-fetching.
- Reusing a computed plan for repeated query shapes so planning cost is paid once, not per request.
Evolving the Graph Safely
A distributed graph is only manageable if you can change it without breaking clients. Federation v2 treats schema changes as something to check before they ship. Composition validates that a proposed subgraph still merges cleanly with the others, and schema checks can compare a change against real query traffic to flag anything that would break existing operations.
In practice this lets each team move independently while the supergraph stays coherent. A subgraph can add fields freely, deprecate old ones with warning rather than removal, and retire them only once traffic confirms nobody depends on them. Federation gives you the structure to grow the graph continuously instead of freezing it out of fear of a breaking change.