In one self-run in-memory store holding both derived copies of catalogue rows and the only record of in-flight claims, how should restart survival, entry lifetime and sizing differ between the two populations?

## Two populations, one component The deployment is one **in-memory store** run by the team itself. The entries in it fall into two populations with two different roles: catalogue rows are a **derived copy** of data a **system of record** still holds, and in-flight claim records are the **sole home for ephemeral state** - nothing else in the system has them. Every setting worth arguing about follows from that distinction rather than from the component. ## The derived copies - **Restart survival**: optional. An empty start means callers read the system of record instead for a while. That period has a cost, but it is a latency and load cost, not a loss of information. - **Entry lifetime**: the deadline is a **freshness bound** - a statement of how stale this copy may be allowed to get. It is a design knob, and shortening it to fit more entries changes only freshness, not correctness. - **Sizing**: the hot subset. Undersizing shows up as more requests reaching the system of record, which is visible and gradual. - **At the memory ceiling**: reclaiming entries under memory pressure is acceptable, because a reclaimed copy can be read again from its authoritative holder. ## The only record of in-flight claims - **Restart survival**: this is now a real decision. Either the store keeps this population across a restart, or the design states the **loss window** it accepts and what the application does with claims that vanish. Not every store in this class offers restart survival at all, and on those that do it is a posture with a running cost - which is why the decision belongs in the design rather than in a runbook. - **Entry lifetime**: the deadline is part of the behaviour. It bounds how long a claim stays in flight before the system treats it as abandoned, so it is chosen from the business process it represents and cannot be trimmed to save memory. - **Sizing**: the **whole live population plus headroom**, computed from the arrival rate and how long an entry lives, not from a hit ratio. There is no such thing as a miss here; there is only an entry that exists or a fact that is gone. - **At the memory ceiling**: reclaiming is silent loss. For this population, a store that refuses further writes at the ceiling is failing loudly and correctly, which is the better failure - provided the application is written to handle a refused write. ## Side by side | Setting | Derived copies of catalogue rows | The only record of in-flight claims | |---|---|---| | Empty after a restart | Slow period; reads go to the system of record | Claims are gone; someone must be told | | Meaning of the deadline | How stale a copy may get | How long a claim stays in flight | | May the deadline be shortened for capacity? | Yes, it changes freshness only | No, it changes what the system promises | | Basis for sizing | Hot subset and hit expectations | Arrival rate multiplied by lifetime, plus headroom | | Reclaimed under pressure | Acceptable | Silent data loss | ## Where stores differ, and why that matters here It is tempting to state ceiling and restart behaviour as properties of in-memory stores. They are not properties of the class: - Some stores **reclaim** entries when memory runs short; others **refuse** further writes; a badly bounded one is simply killed by the operating system. Which of these your store does is something to confirm, not assume. - Some stores keep **nothing** across a restart by design, some offer restart survival as a choice with a cost, and the size of the loss window varies with the posture chosen. - Some acknowledge a write only once another node also holds it, while others acknowledge as soon as the node taking the write has it. That difference is invisible for the catalogue copies and material for the claims. What is universal is the reasoning, not the behaviour: name the role, then confirm what this particular store does at the ceiling and across a restart. ## If they must share one deployment They can, and the arithmetic is simple and unpleasant: **the strictest population sets the posture for the whole deployment**. If the claims must not be reclaimed, the deployment cannot be configured to reclaim freely, so the catalogue copies lose the property that made them cheap - you must now size for the union rather than for the hot subset, and you carry restart survival for entries that never needed it. That is a real cost, and it is the argument for separating the two populations onto different deployments once either is large enough to notice. The decision is not "one tier or two" as a matter of taste; it is whether the derived copies are cheap enough to run under the claims' rules.