A slow dependency turns whole GraphQL responses null at peak — how do you reshape the schema to degrade partially instead?

## What the symptom is telling you A response that arrives as `data: null` with a single error entry is not a transport problem and not a validation problem. Validation failures never execute, so they leave `data` absent rather than null. A `data` that is present and null means execution started, a field could not be produced, and the resulting hole had no nullable position to settle in between that field and the root. The error entry's path names where it started; the schema tells you why it did not stop. At low traffic this is invisible: the dependency answers, the promise holds, nobody notices that the schema has no firebreak. At a 1,200-request-per-minute peak the same dependency's tail latency crosses the resolver's timeout and every request that touches the field returns a blank page. The schema did not change; the failure rate did. That is why this shows up as an incident rather than as a review comment. ## Step one: map the chain, not just the field Take the path from the error entry and walk it in the schema, link by link, from the failing field up to the root operation field. Write down each link's nullability. What you are looking for is the first nullable link — the point at which the loss would have stopped. If there is none, the blast radius is the whole response. In a payroll and benefits graph the chain often looks like `payRun → payslips → benefitElections`, all Non-Null, with the elections served by an external benefits provider and everything else served from the payroll database. One unavailable provider costs thousands of correctly computed payslips. ## Step two: choose the boundary deliberately The schema change is not "make things nullable" but "decide the smallest unit a consumer can still render." Ask the people who build the screens. A payslip without its benefits panel is a usable payslip; a pay run without its payslips is not. So the `!` comes off `benefitElections`, and nothing else moves. Each affected payslip now carries a hole, an error entry names the exact path, and every other field in the response survives. Going coarser — making `payslips` nullable — would also stop the bubble, but it pays the whole pay run to protect one panel. Going finer is not possible: the field is the smallest thing there is. The change has a consumer cost. A field that was Non-Null and becomes nullable widens what every existing consumer must handle, so it is coordinated work rather than a quiet schema push — announce it, give consumers a window, and confirm that the screens actually render the hole rather than crashing on it. ## Step three: reduce the frequency, not just the radius A firebreak converts an outage into a degradation; it does not make the dependency reliable. The second half of the fix is at the resolver: * A **timeout** shorter than the client's patience, so the field yields a null quickly instead of holding the request open. Under load, an unbounded call is worse than a failed one, because slow requests pile up and cost the whole endpoint. * A **circuit breaker** so that once the provider is clearly down, the field fails immediately instead of every request paying the timeout. * A **fallback** where the domain allows one — a last-known-good value with a staleness marker is often better than a hole, and it is a schema decision too, because it changes what null means. ## Step four: prevent the next one The incident is evidence about the whole schema, not just this field. Sweep for other fields backed by a different service or a job that can lag, and check whether each one sits under an unbroken Non-Null chain. A schema linter can enforce a house rule mechanically — for example, that no field resolved across a service boundary may be Non-Null, or that no Non-Null chain from such a field may reach the root. Field-level error-rate metrics make the same point after the fact: a Non-Null field with a nonzero error rate is a mis-marked field by definition, because every one of those errors cost more than itself. ## What to say about the specification None of this is specified behaviour beyond the propagation rule itself. The specification says what happens when a Non-Null position cannot be filled; it does not say where the author should have put the `!`, and it has nothing to say about timeouts, breakers or fallbacks. Those are operational conventions layered on top, and an interviewer will notice whether you attribute them correctly.