A team wants native object-graph snapshots as the cross-service cache format, with per-type version stamps to manage drift; what do you decide?

## What is actually being proposed The proposal is attractive because it looks cheap: no schema to author, no mapping code, no code generation step, and a stamp per type to catch drift. Judging it means separating three questions that get bundled together — what a stamp buys, what the graph costs, and where the boundary should sit. ## What a version stamp buys, and what it does not - **It buys detection.** A stamp or shape token lets a reader notice that the writer's declaration differs from its own, so a mismatch fails loudly instead of producing a half-populated object. - **It does not buy translation.** Knowing that version 3 is not version 5 says nothing about what to do with a field that was split in version 4. Somebody writes that, by hand, per type, per step. - **It is routinely pinned to silence errors.** The stamp is under the type author's control, and the quickest way to make a failing read succeed is to declare the old value. That converts a loud failure into a quiet, half-restored object — the worst outcome of the three. - **It says nothing about intent.** A stamp cannot express that a field became optional, or that an absent value should be treated as a particular default. Those are the evolution rules an explicit contract states and a stamp cannot. ## The cost scales with the graph, not the traffic This is the part teams underestimate. The snapshot covers everything reachable from the root, so every type in that closure is part of the wire contract — including types nobody thinks of as a message, and types owned by other teams. Each one needs a stamp, a discipline about when to bump it, and upgrade handling for each historical shape still present in the cache. The bill arrives in maintenance, long after the decision. ## Which boundaries the family may cross | Boundary | Verdict | Why | |---|---|---| | Inside one process, one build | fine | writer and reader are the same code, alive at the same moment | | Short-lived cache, single service, regenerable on a miss | acceptable with care | a failed read costs a recomputation, not an incident | | Across services or teams | no | the contract has no artifact and no owner, so a refactor breaks a stranger | | Across a release, or into durable storage | no | bytes outlive the code, making the code's shape a permanent contract | | Across a runtime or language | no | reconstruction semantics are private to the writing runtime | | Across a trust boundary | never | the payload names the types the decode path will construct | ## The three questions I would ask before deciding 1. **Can a failed read be turned into a miss?** If the value is regenerable from its source, a version break costs a cold cache. If it is not, a version break costs data, and the family is out. 2. **How long do the bytes live relative to the release cadence?** Bytes whose lifetime is shorter than the interval between deploys never meet code they do not understand. Bytes that persist for weeks certainly will. 3. **Who is allowed to change a type in the graph?** If the answer is any team with a pull request, the contract has no owner and the proposal is already unmanageable. ## The decision, and the thing worth conceding I would refuse a native snapshot as a cross-service cache format and require an explicit encoding for anything crossing a team, a runtime, a trust boundary or a release, because that makes the contract a reviewable artifact with stated compatibility rules. I would not, however, ban the family outright: there is a legitimate use for a short-lived, regenerable checkpoint written and read by one build inside one trust boundary, where the fidelity is genuinely useful and the failure mode is a recomputation. The honest version of the team's argument is not "stamps make it safe" but "we do not want to author a schema" — and that cost is real, one-time, and much smaller than a per-type upgrade matrix maintained forever.