Moving a per-instance copy into one shared tier ends the disagreement between instances — which reads still cannot be trusted to it?

## What the shared placement actually fixes With copies held inside each application process, the fleet holds one version of an entry per instance, and which one a caller sees depends on routing. Move that copy into a **shared tier** — a separate component every instance reaches over the network — and there is exactly one entry. Every instance reads it, so: - two callers served by two instances get the same value at the same instant; - one caller's successive requests return the same value regardless of which instance takes them; - a second system reconciling against yours no longer sees a discrepancy that depends on which process answered; - the memory for the set is held once rather than once per instance. That is a real and often decisive gain, and it is the entire content of the word *shared*. ## What it leaves exactly as it was The entry in the shared tier was written at some earlier moment from the system of record. Nothing about being shared makes it current. The fleet has moved from *variously stale* to *equally stale*, which is a genuine improvement in explicability and no improvement at all in freshness. If your users complained that they saw an old value, the shared placement does not answer the complaint — it only guarantees that everybody sees the same old value. The second thing it leaves — in fact adds — is a dependency. The in-process copy needed nothing but the process. Every read from the shared tier now requires that component to be reachable over the network and able to answer. The placement decision buys agreement and pays for it with a hop and a dependency; that is the trade in one sentence. ## Two properties that are easy to confuse | Property of the read | Per-instance in-process copy | One shared tier | The authoritative holder | |---|---|---|---| | All instances return the same value | no | yes | yes | | Value matches the system of record right now | no | no | yes | | Answerable when the shared tier is unreachable | yes | no | yes | | Cost per read | a local lookup | a hop | the full cost of the source read | Read down the middle column and the shape of the answer is visible: the shared tier is strong on agreement, neutral on currency, and weaker than the in-process copy on availability. ## The reads neither placement can answer - **A read that must be exact at the instant it happens.** Any copy is a statement about an earlier moment. If the decision downstream of the read only holds when the value is current, the read goes to the holder that defines the value. - **A read whose result the caller will treat as authoritative** — for example writing it onward as though it were the source's own answer. A copy cannot confer authority it never had. - **A read that must succeed when the tier is not reachable.** The in-process copy can answer with no dependency, but not with one agreed value; the shared tier can answer with one value, but only while it is up. A read needing both properties at once is satisfied by neither, and the honest design sends it to the source. ## A short review checklist 1. Name what the tier is holding in this design and whether an authoritative holder still stands behind every entry. The rest of the conversation depends on the answer. 2. Ask what complaint the placement change is meant to fix. If the complaint was *stale*, a move from per-instance to shared will not fix it. 3. For each read, decide separately whether it needs agreement, currency, or availability without the tier. Reads that need all three do not belong on a copy at all. ## Where the class varies One caution before asserting anything about the shared side: the behaviour of that component under pressure and across a restart is a property of the specific store, not of the fact that it is shared. Some stores in this class reclaim entries when memory runs out while others refuse the write; some keep something across a restart and others come back completely empty. A design that quietly assumes the shared tier still holds what it held yesterday is assuming one store's behaviour rather than the class's, and the repair is to say which behaviour this design needs and check that the chosen store provides it.