An entry written with a one-hour lifetime is missing ten minutes later - what else removes entries besides a deadline?

## Two removals wearing one symptom An in-memory store takes entries away for two unrelated reasons, and from the caller's side the two are indistinguishable: a read finds nothing where the application expected something. - **Expiry** is the removal the application asked for. Something attached a **lifetime** to the entry - a duration, at the write or afterwards depending on the store - and when the **deadline** at the end of that lifetime passes, the store stops serving the entry. The store is carrying out an instruction it was given. - **Eviction** is the removal the store forced on the application. It needed room it did not have, and it took an entry to get that room. The entry it took may have been nowhere near its deadline, or may have carried no lifetime at all. No application intent explains this removal; only the state of the tier does. An entry ten minutes old that was written with a one-hour lifetime cannot have been removed by its own deadline. The arithmetic rules expiry out, which is what makes this scenario a useful teaching case: whatever removed it, the application did not ask for it. ## A lifetime is an upper bound, not a lower one The common first-screen mistake is to read a lifetime as a reservation - *keep this for an hour*. It is not. It says *stop serving this after an hour*. Nothing in it obliges the store to still have the entry a minute from now. An in-memory store runs against a bounded amount of memory. When a write arrives and the store has no room for it, one of the things a store may do is remove an existing entry to make space. Exactly what a store does when it reaches its ceiling, and whether removing something is what it does at all, is its own subject with its own answer - the relevant point here is only that where a store does remove something, entries still comfortably inside their lifetimes are exactly the material it has to work with. The result is a missing entry that looks identical to an expired one. ## What each removal tells you | | Expiry | Eviction | |---|---|---| | Who asked for it | the application, by attaching a lifetime | nobody; the store forced it | | When it happens | when the entry's deadline passes | when the store needs room it does not have | | What a rising count means | more entries written with lifetimes, or shorter lifetimes | the tier reached its ceiling | | Evidence about capacity | none at all | yes, however small the count | | Where the remedy lives | the lifetimes and the access pattern | how much the tier holds and what is kept in it | The last two rows are the whole reason the distinction is worth holding onto. A tier can remove millions of entries an hour on their deadlines and be nowhere near full; that number tracks how many entries were written with lifetimes and how short those lifetimes were. A tier that forces out two entries a day is telling you it hit its ceiling twice and chose, on your behalf, what your service would no longer find. ## What varies between stores This is a class of products, not one product, and the behaviour around forced removal is one of the places they genuinely differ: - **Whether the store removes anything at all** when it cannot fit a write. Some do; on others it is a configured posture rather than a given. - **Which entries are candidates.** Some stores consider only entries that carry a lifetime, so an entry with no lifetime is untouched by pressure. Others consider the whole keyspace. This difference decides whether "it has no lifetime, so it will be there" is a safe assumption or a bet on one product. - **What the store reports.** Most expose a count of removals it performed under pressure, but not all expose the two counts separately, and an entry already past its deadline that the store finally reclaims because it needed the room may be booked under either name. - **Whether anything is announced.** Some stores can emit a message when an entry is reclaimed; where they do, it is best-effort and emitted when the reclaim happens rather than when the deadline passed. Others emit nothing. So the safe general statement is the narrow one: a deadline is a promise about when the store stops serving an entry, and an entry can also go for reasons the application never asked for. ## Other reasons an expected entry is missing Before blaming either removal, rule out the explanations that are neither: 1. Another caller issued an explicit delete. 2. The write never landed - it failed, or it was sent to a different key than the read. 3. The node holding the entry restarted, and an in-memory tier may come back empty. 4. The read was served by a copy of the tier that has not received that write yet. Only after those are excluded is it worth asking which of the two removals happened, because each verdict points somewhere completely different.