When a store cannot see inside a value, what must every service that reads or writes that entry agree on, and who enforces it?

## The store is not a schema A **byte-opaque store** takes a key and a sequence of bytes and gives that sequence back unchanged. It does not parse the value, does not know what fields are inside it, and will not refuse a write because these bytes are shaped differently from the last ones. That property is what keeps the store simple and its cost model flat — and it is also what moves an entire class of guarantees out of the store and into your code. The thing the services must then agree on deserves its own name: **the shared value format** — the serialized form every writer produces and every reader must be able to consume. ## What the agreement actually covers More than "we all use the same serializer". A working agreement pins down: - **the serialization and the settings that change the bytes** — field ordering, number handling, text encoding; - **the field names and their meanings** — an expiry field holding an instant in one service and a duration in another is a silent, data-losing disagreement that no type system catches; - **which fields are required and which may be absent**, and what a reader should conclude from an absent one; - **the difference between "absent" and "present but empty"**, which two teams will otherwise settle differently; - **the representation of time, money and identifiers** — the three things a format gets wrong at least once; - **what a reader does with a field it does not recognise** — ignore it, or fail. That last decision is not a detail. It is the single choice that determines whether the format can ever change while the fleet is running. ## Who enforces it, since the server will not 1. **One library, not one document.** The format lives in a library every writer and reader depends on: it owns the serialization and the field definitions, and the services own only the business meaning. A format described on a wiki page is enforced by nobody. 2. **A version marker inside the value.** One field saying which shape this is, written by every writer and checked by every reader. It costs a few bytes and it is the difference between a readable failure and a baffling one. 3. **Tolerant readers.** A reader that ignores unknown fields and supplies a default for absent ones survives a writer that is ahead of it — and during any gradual deployment, some writer always is. 4. **A test that crosses the boundary.** Something in the pipeline must deserialize a value produced by the current writer using the current reader. Otherwise the agreement is asserted, not verified. ## How much help the server gives, and how much it varies | The server… | What it does enforce | What it still does not | |---|---|---| | hands back bytes only | nothing at all about the value | field names, types, units, meanings, versions | | can address named fields inside a value | that named fields exist and can be read one at a time | what a field means, its unit, whether it is required | | can index or query values | more, at the cost of tying your model to that store | the semantics your application attaches to the data | Stores in this class sit in different rows, so it is worth saying which row you mean rather than assuming one. Even in the middle row the server knows field *names*, not field *meanings*: it will happily let one service write a duration where another expects an instant. The agreement problem shrinks; it does not disappear. ## What the missing guardrails buy you It is a trade, not a deficiency: - **Portability** — a value the server does not interpret moves to any other store of this class unchanged. - **Predictability** — the server does no work proportional to the structure of your data. - **Freedom of shape** — the format is yours, nothing in the store has an opinion about it, and nothing inside the store has to be migrated when it changes. ## The failure mode this produces A format disagreement on a store that cannot see inside a value does not fail at write time, when you could still catch it cheaply. It fails on the **reader**, later, in a different service, possibly in a different team's on-call rotation. And because this is a volatile tier, the offending entries may have expired or been evicted before anyone goes looking — so the evidence is gone and the report is "it happened twice this morning". That asymmetry, rather than the choice of serializer, is what the question is really about. The one consolation the volatile tier offers is that the exposure is bounded: entries carrying a lifetime age out on their own, so a bad format stops circulating once the writers producing it are gone, which is not true of the same mistake made in a durable store.