Why can the role you pick for a volatile tier rule out some in-memory stores before you compare them?

## The role narrows the field before the comparison starts It is common to choose an in-memory store first - by familiarity, by what the platform team already runs - and then decide what to keep in it. That order hides a real risk, because the four roles ask for different things and stores of this class differ from one another far more than their shared description suggests. Deciding the role first turns a vague comparison into a short list of required capabilities. ## What actually varies between stores of this class - **Delivery to listeners.** Some stores offer a way to push something to whoever is connected at that moment; others have no such mechanism at all. This is binary and decisive: without it, the **transient transport** role does not exist on that store, and no configuration produces it. - **Restart survival.** Some stores keep nothing across a restart by design; others offer it as a posture with a running cost and a loss window whose size depends on the posture chosen. Decisive for the **sole home for ephemeral state**, irrelevant for a **derived copy**. - **Behaviour at the memory ceiling.** Some stores reclaim entries under memory pressure; others refuse further writes. For a derived copy, reclaiming is fine and refusal is an outage. For state with no other holder, the preference inverts: reclaiming is silent loss and a refused write is the safer failure. - **When a write is acknowledged.** Some stores acknowledge as soon as the node taking the write holds it; others only once another node holds it too, and some make that a per-call choice. Invisible for a derived copy, material for the sole-home and coordination roles. - **What the server can do to a value.** Some stores hand back only the bytes they were given, so any change is a full read-modify-write by the caller; others can read and change part of a value. This shapes how a **coordination point** is built and what a design must do to keep two callers from overwriting each other - the mechanisms themselves are a separate subject, but their availability is a property of the store. - **Who operates it.** The same nominal store reached as a **managed in-memory service** offers a different set of postures and controls than one you run yourself, so "which store" and "in what shape" are two answers, not one. ## Worked: two roles, two short lists 1. A design wants a **transient transport** - notifications to whichever application instances are connected now, with nothing retained. The required capability is delivery to listeners, and every store lacking it is eliminated immediately, whatever else it does well. If the review then discovers that disconnected listeners must also receive the item, the requirement has changed shape entirely and a retained log is the component being described. 2. A design wants a **coordination point** - one shared place where processes agree who holds something. The required capabilities are an operation the store makes atomic for the caller, a deadline on the entry so a process that dies releases what it held, and a clear statement of what a failover does to entries written just before it. A store that cannot state the last of those has not been ruled out, but the design now carries a risk it has to name. ## Why this cuts both ways The same reasoning stops the opposite error: rejecting a store because it lacks something the chosen role never needed. A store that hands back only opaque bytes and keeps nothing across a restart is a perfectly good home for a **derived copy**, because the system of record still holds every value and an empty start is a slow period rather than a loss. Requiring restart survival there buys nothing and costs throughput. ## The order of decisions 1. Name the role each entry population is in. 2. Derive the capabilities each role requires - delivery, restart survival, ceiling behaviour, acknowledgement, value handling. 3. Confirm what the candidate stores actually do on each of those axes, rather than assuming the behaviour of the one you know best. 4. If several roles must live on one deployment, take the union of the requirements and price it, because the strictest role dictates the settings for everything on that deployment. The habit that makes this work is refusing to state any of these behaviours as a property of the class. "It persists", "it evicts when full", "it runs one operation at a time", "it requires a credential" are each true of some stores in this class and false of others; treating any of them as universal is how a design ends up needing a capability that the chosen store never had.