When publishing one node of a deeply linked build graph to another team, how deep should the serialized form reach?

## The question behind the question A node in a build graph reaches, transitively, most of the graph. 'Serialize this node' is therefore not well defined until someone says where the walk stops. That decision is the single most consequential one in a published message, because it fixes the payload's size, its consistency guarantee, and the set of schemas you have coupled yourself to. ## The two ends **Deep cut — embed the transitive closure.** - The consumer gets everything in one read, with no follow-up calls and no partial view. - The embedded subgraph is a **consistent snapshot**: every node was read at one moment, so the consumer never sees a mixture of versions. - But the payload grows with the graph, and the growth is usually worse than linear, because a shared node reached by several paths is embedded once per path unless identity indirection is in the contract. - Every reachable type's schema is now part of **your** published contract. When a team three hops away changes their node's shape, your consumers feel it, and you are the one who fields it. - You may embed nodes this consumer is not entitled to read, turning a shape decision into an authorization decision. **Shallow cut — emit identifiers.** - Small, stable payload; your contract covers your node and nothing else. - The consumer resolves what it needs and caches each referenced node independently, which is efficient when consumers need very different slices. - But a consumer that needs the neighbourhood now issues one fetch per reference, and a list of such nodes multiplies it. - Its reads **tear**: each referenced node is fetched at its own moment, so the assembled view may mix versions that never coexisted, and nothing in the payload says so. | Dimension | Deep cut | Shallow cut | |---|---|---| | Payload size | Grows with the reachable graph | Bounded by your node | | Consistency | One snapshot across the subgraph | Per-reference, may tear | | Schema coupling | Every reachable type joins your contract | Your node's type only | | Consumer round trips | One | One per reference it resolves | | Caching | All or nothing, per message | Per referenced node, reused | | Authorization | Must be decided per embedded node | Enforced where each node is fetched | ## The middle that usually wins 1. **Find the boundary of the consumer's unit of work.** Embed the nodes it cannot act without — the ones whose absence makes the message useless — and reference the rest. Where both sides already share a notion of an aggregate, that boundary is the obvious cut. 2. **Make each reference useful on its own.** A bare identifier guarantees a follow-up fetch. A stable identifier plus the two or three fields the consumer needs to display or filter — a name, a kind, a status — removes most of the amplification while keeping the other team's schema out of your contract. 3. **Say what the snapshot means.** Stamp the message with the moment the embedded subgraph was read, so a consumer that resolves a reference later can tell that what it fetched may be newer than what it was given. 4. **Pick the cut per consumer type, not per encoder.** Several messages carrying different depths of the same graph is an honest design; one message that serves everybody tends to be deep for those who wanted small and small for those who wanted deep. When the same graph must serve genuinely different consumers, the alternative to guessing is to let the consumer state the depth it wants and to answer only within a published maximum. That trades a simpler payload for a more complex contract, and is worth it only when the consumers' needs really do diverge. ## Signals that the cut is wrong - Consumers routinely fetch the same set of references immediately after receiving your message — the cut is too shallow for their unit of work. - Your compatibility reviews keep being triggered by changes to types you do not own — the cut is too deep. - Payload size tracks the graph's growth rather than the entity's — the closure is being embedded where references belong. - Two consumers disagree about the same entity because each resolved its references at a different moment — consistency was never stated. ## What an interviewer is listening for That you refuse the framing of one universally right depth; that you name the three axes that actually decide it — consistency, coupling and amplification — and pick a cut you can defend for a stated consumer; and that you recognise the deep cut's quiet cost, which is that you have adopted other teams' schema changes as your own compatibility obligation.