In a federated graph, why does the router batch entity fetches instead of one call per item?

## What "fetch amplification" names A federated graph is one client-facing schema composed from several subgraph schemas. The router accepts the client's document, works out which subgraph owns which field, and issues its own requests to those services. Fetch amplification is the ratio between what the client asked for — one document — and what the router had to do downstream. The dangerous case is when that ratio scales with the *data*: a list of 20 items costs 20 calls, a list of 143 costs 143. Take a museum collection graph. A **Catalog** subgraph owns `Artwork` with `@key(fields: "id")` and the `Exhibition.artworks` list. A separate **Conservation** subgraph contributes `Artwork.conservation`, holding condition reports the curators keep out of the catalogue database. A curator opens an exhibition floor plan: ```graphql query ExhibitionFloorPlan { exhibition(id: "EX-1913") { title artworks(first: 143) { title accessionNumber conservation { status lastInspected } } } } ``` Catalog answers `exhibition`, `title`, `accessionNumber`. Every `conservation` value lives in another process. The naive shape is one request per artwork: 143 HTTP calls for one screen. ## Why this is worse than an in-process N+1 The classic N+1 costs a database round trip per item. Here each item costs a full service call: connection acquisition, JSON serialization on both sides, an auth check, network latency, and a second execution of the whole GraphQL pipeline in the subgraph. At an unremarkable 6 ms per call, 143 sequential calls are the better part of a second of pure overhead; issued concurrently, they arrive at Conservation as a burst that can saturate its pool and slow every other caller. The multiplier is also invisible from the client side — the document looks small, and the amplification only shows up in the subgraph's request count. ## The batched entity fetch Apollo Federation's subgraph specification exists partly to make one call enough. Every federated subgraph exposes a reserved root field: ```graphql _entities(representations: [_Any!]!): [_Entity]! ``` The argument is a **list**. The router collects the key fields of all 143 artworks, builds one representation per item — each an object carrying `__typename` plus the key fields — and sends a single query: ```graphql query($representations: [_Any!]!) { _entities(representations: $representations) { ... on Artwork { conservation { status lastInspected } } } } ``` Conservation returns one list, the router splices each element back into the position it came from, and the client sees an ordinary nested response. One plan step, one call, whatever the list length. That list-shaped argument is the whole reason cross-service amplification is bounded at all — it is a composition-specification concept, not something the GraphQL specification itself defines. ## What batching bounds, and what it does not It bounds **calls between services** for one step of the plan. Three things it does not bound: *The work inside the subgraph.* Conservation now receives 143 keys in one request. If its `conservation` resolver loads one condition report per key, the N+1 simply moved across the wire — same 143 database round trips, now hidden inside a single HTTP call that looks healthy in the router's metrics. Cross-service batching and in-service batching are separate defences, and each only fixes its own layer. *The number of steps.* Nesting creates new steps. If each artwork's conservation record exposes a conservator who owns further artworks, the plan gains another entity fetch, and its representation count is the product of the fan-out above it. Deeply nested documents — the pathological ones run to 19 levels — turn a handful of steps into a long chain, each fed by a wider list than the last. *The size of the one call.* A batched fetch converts many small requests into a single very large one. That is usually the right trade, but it moves the risk from call count to payload size and blast radius. ## What an interviewer is listening for Count network calls per plan step, not rows. Say plainly that the fix is the list-valued `representations` argument rather than "the router is smart". And name the boundary: a batched entity fetch is a promise about the number of service calls, never a promise about the number of queries the receiving service runs.