In a federated supergraph, what is a satisfiability error when every subgraph schema is valid on its own?

## Two different checks wear the name "composition error" The first check is a merge check: two subgraphs declare the same field with different types, or an enum drifts, or an argument list disagrees. Those are local, and the error points at two declarations you can put side by side. Satisfiability is the second check, and it is global. Once the merge succeeds, composition still has to prove that the graph it just built is actually executable: for every field in the supergraph, and for every route a client could take to arrive at it, there must exist a query plan that reaches it. That proof can fail even though every subgraph is a flawless GraphQL schema, and even though no two declarations conflict. It is the check that catches a graph which is well-typed but not traversable. ## How the router moves between subgraphs A plan starts at a root field in one subgraph. To continue into another subgraph it has to hand that service an identity it can look up — the fields named in a `@key` the target subgraph declares on the type. If the target subgraph declares no key the router can build, or declares one whose fields the current subgraph cannot produce, the jump does not exist. There is no fallback: the router will not query a service on an identity that service never declared it could resolve. A farm-sensor graph shows it in three lines of drift. A Devices subgraph owns the hardware: ```graphql # Devices subgraph type Sensor @key(fields: "id") { id: ID! model: String! } ``` An Agronomy team then adds soil moisture. Their store is keyed by the manufacturer's serial number, so they write what is natural in their own repository: ```graphql # Agronomy subgraph type Sensor @key(fields: "serialNo") { serialNo: String! soilMoisturePct: Float! } ``` Both files are valid. Both services start and pass their own tests. But a client asking `sensor(id: "snsr-40917") { soilMoisturePct }` starts in Devices, which has an `id` and no `serialNo`, and Agronomy will only be entered with a `serialNo`. No plan exists, so `Sensor.soilMoisturePct` is unreachable from that route and composition refuses the supergraph. ## Why it fails at composition time rather than at runtime A graph like the one above is not broken for *every* query. If Agronomy also had a root field returning sensors, the field would be reachable by that route and unreachable by the other. Allowing that would mean shipping a schema where a field's availability depends on how the client happened to navigate to it — the same selection succeeding under one parent and failing under another, discovered by a client in production rather than by the team at build time. Federation composition rejects that class of graph up front instead, which is the same fail-closed instinct behind refusing to emit a partial supergraph. ## Reading the error on a large graph On a 62-subgraph supergraph the message is long, and the useful habit is to read it backwards. It states the field that could not be reached, then the path the planner tried, then the reason each candidate move was rejected — typically that the type has no key it could use in the target subgraph, or that a field's declared dependency on sibling fields cannot be satisfied on that route. Three things then explain almost every occurrence: - **Key mismatch.** Two subgraphs key the same entity on fields neither can give the other. The fix is a key both sides can produce — usually adding the graph's canonical identifier to the newcomer's declaration, backed by a lookup in their store. - **A shared type that was never made an entity.** A type declared in two subgraphs with no key at all cannot be jumped into. Either it becomes an entity with a key, or one subgraph stops declaring the extra fields and reaches them another way. - **An unmet field dependency.** A field declared to depend on sibling fields owned elsewhere is only reachable where those siblings can be fetched on the way. Add the missing route or move the field to the service that already holds what it needs. ## The judgement an interviewer is listening for Two things. First, that you can say why the check exists at all — a merged schema being well-typed says nothing about being executable, and satisfiability is the property that fills the gap. Second, that you treat it as a graph design signal rather than a build annoyance. A satisfiability failure usually means a team put a field on an entity their service cannot independently identify, and the durable fix is a key discipline — one canonical identifier per entity that every subgraph touching it can resolve — not another directive bolted on until the build goes green. It is also worth being precise that none of this is the GraphQL specification: reachability across services is a federation composition concern layered on top of a specification that only ever validates one schema.