How do you place nullability in a GraphQL schema so one failing field cannot blank the whole response?

## What `!` buys, and what it charges In GraphQL, `!` marks a position as **Non-Null**: the server promises the client that this position will never hold null. That promise is worth something. A consumer needs no branch, and a typed client generator emits the member as required rather than optional. But the promise has to hold on the worst day too, and when it cannot, GraphQL does not quietly put a null in the slot. The unfulfillable Non-Null position is resolved by nulling the **nearest nullable ancestor**, and everything that had already resolved underneath that ancestor — sibling fields, sibling list entries — is discarded with it. So a `!` is not a free ergonomic win. It is a statement of the form *"if this value is missing, throw away everything down to here."* The region thrown away is that field's **blast radius**, and the schema author is the only person who chooses it. ## Reading a schema for blast radius The procedure is mechanical. Start at a field you consider risky — typically one backed by a separate service, a queue, a cache that can miss, or a computation with a timeout. Walk upward through its parent fields to the root operation field. Stop at the first link whose type is **not** Non-Null. Everything beneath that link is the blast radius. If you reach the root without finding a nullable link, the blast radius is the entire response: the client gets `data: null` and none of the work that succeeded. Consider a payroll and benefits graph in which every link is Non-Null: ```graphql type Query { payRun(id: ID!): PayRun! } type PayRun { id: ID! periodEnd: Date! payslips: [Payslip!]! } type Payslip { id: ID! netPay: Money! benefitElections: [BenefitElection!]! } ``` `benefitElections` is served by the benefits provider; `id` and `netPay` come from the payslip row the parent already loaded. The chain from `benefitElections` to the root has no nullable link, so when the provider is unreachable for one employee out of 4,300, the response for the entire pay run is `data: null`. Thousands of correctly computed payslips are dropped because one optional-looking side panel could not be filled. ## Placing the firebreak The design question is not "should this be nullable?" in isolation. It is: **what is the smallest unit of the response a consumer can still use without this field?** Make the link at that boundary nullable, and leave everything else alone. In the example the answer is a single payslip's benefits panel, so `benefitElections` itself becomes nullable. One payslip now arrives with a hole where the elections were; every other field of every payslip survives. Making `payslips` nullable instead would be a firebreak too, but a badly placed one — it costs the whole pay run to save the same panel. Making the root `payRun` nullable is no firebreak at all: it is where the damage was already going. Two heuristics decide most fields: * **Non-Null is cheap when the field comes from the same load as its parent.** If the parent object exists, the field exists: an identifier, a column of the row in hand, a value computed from data already present. There is no separate way for it to fail. * **Non-Null is expensive across a boundary.** Another service, a network hop, a cache miss, a nightly job that may not have run. Each of these fields is a fuse, and the `!` on it and on every ancestor sets how much burns. List fields carry two independent decisions — the list itself and each element — and choosing them per element is its own exercise; the point here is only that both wrappers are part of the same chain. ## The cost of over-correcting "Make everything nullable" is not the answer either. Every nullable field is a branch in every consumer, and a null becomes ambiguous: for a nullable `benefitElections`, null may mean *this employee has no elections on file* or *we could not reach the provider*, and the two are distinguishable only by whether the response's errors list carries an entry whose path points at that field. Nullability is a budget, spent where it buys resilience and saved where it buys clarity. ## Say that the specification is silent The GraphQL specification defines the Non-Null wrapping type, defines what happens when a null lands in a Non-Null position, and defines the error entry that accompanies it. It says **nothing** about where a schema author should put `!`. The house rules you will hear — *non-null only what you can always produce*, *nullable across a service boundary*, *non-null identifiers* — are widespread convention, not specified rules. Saying that out loud in an interview is worth as much as the placement heuristic itself, because it shows you know which part of GraphQL is a standard and which part is taste.