A running in-memory store exhausts the memory available to it: what three outcomes can follow, and how does each appear to the caller?

Memory is the one resource in an in-memory store whose exhaustion is **configured rather than fated**. A disk fills and writes fail; a network partitions and calls time out. Memory runs out and the store does one of three quite different things — and which one it does was decided in advance, usually by whoever accepted a default without reading it. ## One condition, three endings The condition itself is dull: the store needs bytes it cannot get. What makes it interesting is that two limits are in play, not one. - **The memory ceiling** is the store's own configured limit, enforced by the store's own code against the memory it attributes to its entries. - **The machine limit** is what the operating system or the container will actually let the process hold. A store that has a ceiling below the machine limit reaches its own ceiling first, and its own code chooses the outcome. A store with no ceiling concept at all, or with one set at or above the machine limit, never gets to choose — the operating system chooses for it. That single structural fact is why the third outcome exists. ## Outcome one: writes are refused The store keeps everything it holds and starts failing the calls that would need more memory. From the caller's seat this is a **partial outage**: the write path errors, while reads of entries already stored generally continue to succeed, because serving an existing entry needs no new memory for it. (The honest qualifier: a read that has to assemble a large reply still needs memory, so refusal is not a guarantee that every read survives.) This outcome is **loud and recoverable**. Nothing already stored is lost, the failure arrives at the caller with a return value attached, and somebody's monitoring can see it immediately. What the application should do about a refused write — retry it, drop it, route it elsewhere — is its own subject. ## Outcome two: entries are removed The store makes room by deleting entries it still holds. This is **eviction**: removal triggered by the ceiling. It is not the same event as **expiry**, which is removal because an entry's lifetime elapsed — same disappearance, different trigger, and only the first one is caused by memory pressure. The caller is told nothing. The write that triggered the removal succeeds normally. The loss surfaces later, somewhere else, as an entry that is simply not there — indistinguishable from one that was never written. This outcome is **silent and lossy**, and whether "lossy" matters turns on one question: *does the removed entry have a source of truth?* If it is a copy of something stored durably elsewhere, removal costs a slower read later. If it is the only copy — a session, a lease, a counter, a record that a job already ran — removal is data loss with nothing to re-read. ## Outcome three: the process is killed When the process reaches the machine or container limit, the operating system ends it. Where paging to disk is available, this is preceded by paging: the process's memory moves to disk, and operations that took microseconds start taking milliseconds. **This is why "it just got slow" is usually the third outcome arriving.** Where paging is disabled or unavailable — common in containers — there is no slow phase at all and the kill is abrupt. The kill is **total**: the whole keyspace goes at once, and the store logs nothing about it, because the decision was made outside the process. ## The three side by side | Outcome | What the caller sees | What is lost | How loud | |---|---|---|---| | Writes refused | Errors on writes, reads still served | Nothing already stored | Loud, immediate | | Entries removed | Nothing at the time; absence later | The removed entries | Silent | | Process killed | Rising latency, then no store at all | The entire keyspace | Total, external | ## Reading the outcome back from the symptom 1. Write calls failing while reads keep working for minutes on end → the store is refusing. 2. Entries missing that nobody deleted, with no errors anywhere → the store is removing. 3. Every operation slowing, then the process gone with nothing in its own log → the operating system killed it (abruptly, where paging is unavailable). ## What varies between stores None of this is uniform across the class, and asserting one store's behaviour as the model is the classic mistake: - whether a refusal posture exists at all — some stores in this class only ever remove; - whether the default is to refuse or to remove, which differs between implementations; - whether the store has a ceiling concept of its own, or leaves the limit entirely to the operating system; - whether removal may take any entry or only entries that carry a lifetime; - whether the ceiling is enforced against what the store attributes to its entries rather than against the process's resident size — where those two diverge, the process can exceed the machine limit while the store still believes itself under its ceiling, which turns an expected outcome one or two into an unexpected outcome three.