As a platform owner, what rule would you set for services relying on partial updates inside stored values, knowing the tier could later be byte-opaque?

## What the rule is actually about It looks like a technology choice and it is not. Whether a service relies on the server changing part of a value decides three things at once: how many round trips its hot path costs, how exposed it is to two writers overwriting each other, and how much of its design has to change if the tier underneath it is ever a **byte-opaque store** — one that returns exactly the bytes it was given and has no operation that reads or changes part of a value. Stores in this class genuinely sit on both sides of that fork, and a platform outlives any one of them. So the question a lead owns is not "which store" but **"what does the shape of an entry commit us to, and who is allowed to make that commitment"**. ## The two absolute rules, and why both fail - **"Ban partial updates; keep everything portable."** Every service now pays a read-modify-write round trip for every partial change: two network operations, the whole entry moved on each, and a window in which a concurrent writer's change can be overwritten. You have bought an option on a store migration that may never happen, and charged the bill to every hot path in the company. - **"Use them everywhere; that is what the store is for."** Now the store's capabilities are woven into every service's data model. The migration you refused to plan for becomes a rewrite of dozens of services rather than a redeploy, and the price is paid all at once, under time pressure, by whoever is on call. Both rules are attractive because they need no judgement. That is exactly what makes them the wrong answer to a principal-level question. ## A rule that survives contact 1. **Classify entries by how they are updated, not by what they contain.** Three buckets: replaced wholesale on every write; one part changed often while the rest sits still; written by several callers at once. 2. **Default the first bucket to opaque.** If a write replaces the entry anyway, a shape the server understands buys nothing and costs per-part overhead. These entries stay portable for free. 3. **Sanction a shape the server understands for the other two, with a stated reason.** Entry size times write rate is the latency argument; several writers on one key is the correctness argument. Require the reason in writing, because it is also what tells you later whether the commitment is still earning its keep. 4. **Require a named fallback.** For every sanctioned entry, one line describing what it becomes on a store that cannot see inside a value — usually the same data as a single serialized value plus whatever the service must then do about concurrent writers. If nobody can write that line, the design is not understood well enough to approve. 5. **Own the shared value format centrally.** One library, one version marker, tolerant readers. This is the part that pays off regardless of which store you are on, and it is the part most often left to each team. ## What the three buckets actually commit you to | Entry profile | Sanctioned shape | Cost of moving to a byte-opaque store | |---|---|---| | Small, replaced on every write | opaque value | none — it already works that way | | Large, one part changed often | a value the server can address in part | every change becomes a read-modify-write round trip; latency and bytes rise | | Written by several callers at once | server-side change of one part | the overwrite exposure returns and needs an explicit remedy | | Single number changed constantly | server-side arithmetic on the value | usually survives, since many opaque stores offer whole-value arithmetic | The last row is the one people get wrong in both directions. "Byte-opaque" restricts *partial* access; it does not mean the store has no server-side operations at all. ## Why the volatile tier makes this a smaller bet than it looks This is the part a principal should raise unprompted. These entries are **not the record of truth**. There is no schema migration, no backfill, no historical data to keep decoding: you deploy services that write the new shape, and the old entries age out under their own lifetimes or are replaced by the next write. The expensive part of a store migration in a durable system — moving the data — mostly does not exist here. What *is* expensive is the application logic that assumed a part of a value could be changed in one operation, and the concurrency assumption underneath it. That is why the fallback line in step four is the substance of the rule and the classification is only its filing system. ## How you would know the rule is wrong - Every service ends up in the sanctioned bucket — the bar is too low, or the classification is being applied after the design rather than before it. - Nobody ever asks for an exception — the rule is not being read. - The fallback lines are all copies of one another — they are being written to satisfy the process, not to describe a real path. - A service's hot path shows two operations where the design said one — the entry was classified as opaque and is being partially updated anyway, which is the case the rule exists to catch.