How do you decide which subgraph should own a field so that query plans stay shallow?

## The decision is not "where does this field belong" Asked abstractly, field placement has a tidy answer: a field belongs with the team that owns the data behind it. Asked in the context of a real graph it is messier, because that tidy answer is also what produces four-round plans on your busiest screen. The honest framing for a lead is that placement trades three things against each other — **latency**, **ownership clarity**, and **change cost** — and that no rule resolves all three at once. ## Start from traffic, not from the schema The common failure is to survey the whole composed schema hunting for deep paths. Most of them do not matter. On a job-board graph, ten operations typically carry the overwhelming majority of volume: the search results page, the posting detail, the application list, the employer dashboard. Plan those, record their depth, and give *those* a budget. A five-round plan behind an internal reporting screen used twice a day is not a problem worth a cross-team migration, and treating it as one spends the organisation's appetite for schema change on something with no return. ## The levers, with their costs said out loud **Move the field.** Cleanest for latency when the field's data genuinely sits with the objects that need it, and it usually also improves the model. It moves on-call and roadmap ownership with it, which is why it is a negotiation and not a pull request. Federation gives a directive for taking over a field from another subgraph so the move can be staged rather than done as a flag-day cutover. **Promise the field inline.** When an intermediate subgraph already has a borrowed value in hand, it can declare that it can supply it, which lets the planner skip a round for that path. This is the cheapest lever when it applies, and its failure mode is subtle: the promise holds only where it was declared, so the same field elsewhere in the graph still costs a hop, and a plan that looked shallow for one operation is not shallow for another. **Duplicate a small, stable field.** Verification status, a display name, a currency code — fields that are tiny, change rarely, and are read constantly. Duplicating one across two subgraphs removes a hop outright and buys an obligation: two writers, or one writer plus a propagation path, and a real answer to what a reader sees during the window in between. Worth it for a handful of fields, corrosive as a habit, because a graph where every subgraph carries a copy of everything has stopped being a federated graph. **Reshape the operation.** Sometimes the fix is not the schema. Splitting a deep branch out of the first-paint request and fetching it after render removes it from the critical path without any cross-team negotiation at all. This is frequently the fastest available win and it is routinely overlooked because it lives on the calling side. **Consolidate a boundary.** If two subgraphs are so entangled that every interesting operation crosses between them repeatedly, the question is not where a field goes; it is whether the split is real. Boundaries drawn around teams that later merged, or around a decomposition that never finished, produce depth that no per-field decision fixes. ## The constraint people forget Callers you cannot redeploy. Shipped mobile builds hold documents you no longer control, and they will keep sending them for as long as those versions are installed. That has two consequences for this decision. First, changing where a field lives must be invisible in the composed schema — same name, same type, same nullability — or you have made a breaking change dressed as an optimisation, and a rename here is exactly how a mobile release breaks in the field weeks after the schema merged. Second, the operations you must protect are the ones already in flight, which means the traffic sample you plan against should come from real observed documents rather than from what the current front end happens to send today. ## Making it a process rather than a heroic The part a lead actually owns is turning this from occasional archaeology into something routine. Composition already runs in a pipeline before deployment; planning a fixed set of important operations against the newly composed schema and comparing their depth to the previous one is a mechanical addition to it. Then a change that pushes a hot operation from two rounds to four fails a check with a named owner, instead of arriving as a latency alert three weeks later that three teams each investigate separately and each conclude is not theirs. That last outcome — every service healthy, the composed query slow, nobody accountable — is the organisational failure mode this whole discipline exists to prevent.