When a federation router builds one _entities call, why does it deduplicate representations?

## The same entity, many positions In a federated response, one entity is frequently referenced from many places in the same list. In a museum collection graph, an exhibition of 143 artworks may be the work of only 37 artists — a retrospective is often a dozen artists and one prolific studio. When the client asks for each artwork's artist name, held in a **People** subgraph while **Catalog** owns the artwork, the router has 143 *positions* to fill but only 37 *distinct keys* to ask about. Deduplication is the step that collapses the second number into the first. Before issuing the entity fetch, the router groups the representations it built — each an object of `__typename` plus the key fields — and drops the repeats: ```json { "representations": [ { "__typename": "Artist", "id": "PER-8811" }, { "__typename": "Artist", "id": "PER-8811" }, { "__typename": "Artist", "id": "PER-2094" } ] } ``` becomes two representations, not three. The subgraph resolves 37 artists, the router keeps a map from each key back to every response position that referenced it, and the single returned object is spliced into all of them. ## Why it is worth doing The saving is proportional to the reference skew, and real graphs are skewed: authors, artists, tenants, categories, currencies, conservators. Three costs shrink together. The request body shrinks — 4,812 bytes of repeated ids is not nothing when representation lists run to thousands. The subgraph's work shrinks, because its work is proportional to distinct keys rather than to positions, whether it loads them one by one or in a batch. And the response shrinks, because the entity list comes back with 37 elements rather than 143 copies of the same object. Note what does *not* change: the client's response. Deduplication happens entirely below the response-shaping layer. The document asked for an artist under each of 143 artworks and gets 143 artist objects; whether they were fetched once or 143 times is invisible. ## Specified, or convention? This is the part that separates a candidate who has read the specification from one who has read a blog post. The Apollo Federation subgraph specification defines the `_entities` field, the `_Any` scalar for representations, and the requirement that the returned list align positionally with the input list. It does **not** require a router to deduplicate. Deduplication is a router-side optimization: some implementations do it, some do it only for simple keys, some make it configurable, and none of that changes whether a subgraph is correct. The practical consequences all follow from that: *A subgraph must tolerate duplicates.* If the same representation arrives twice, return the entity twice, once per position. Failing, collapsing the list, or returning a shorter list breaks the positional contract. *A subgraph must not count entity resolutions as usage.* If a conservation-audit table writes one row per resolved entity, the count answers "how many distinct keys were asked for", not "how many times a curator looked at this artist" — and it changes silently when the router's deduplication behaviour changes. Usage belongs in a metric derived from the client document, not from entity resolution. *A subgraph must still batch internally.* Thirty-seven keys in one call is thirty-seven lookups unless the subgraph loads them together. ## When identical entities fail to coalesce Two representations coalesce only when they are actually identical. Several situations break that: **Composite and nested keys.** A key of `@key(fields: "provenanceLot { id } accessionNumber")` produces a nested object; whether two such objects compare equal depends on the router normalizing them, not on the entity being the same. **Extra fields pulled in by a `@requires`.** When a field the subgraph resolves declares that it requires sibling fields, those values ride along inside the representation. Two references to the same artist can then carry different accompanying values and are, correctly, not the same representation. **Multiple keys on one type.** A type may declare more than one key; two references reaching it through different keys produce structurally different representations for the same underlying row. ## The interview register This is not a question anyone's offer turns on — it is a curiosity that reveals whether you picture the entity fetch concretely. The strong answer is two sentences of mechanism and one of caveat: the router collapses repeated keys because the subgraph's cost tracks distinct entities, and because it is an optimization rather than a specified rule, nothing in a subgraph may depend on it happening.