Under memory pressure, may a store remove an entry whose deadline has not arrived, or one carrying no lifetime at all?

## What a lifetime actually promises A lifetime attached to an entry is a statement about service: after the deadline at its end, the store stops serving that entry to readers. It is an **upper bound** on how long the entry is available. Read as a lower bound - *this will be here for the next ten minutes* - it produces two separate surprises in production, and both of them have to be met head-on rather than treated as anomalies. ## Surprise one: the entry that goes early A store runs against a bounded amount of memory. Where a store responds to a write it cannot fit by removing an existing entry, the entries available to it are, by definition, entries nobody asked it to remove. An entry with fifty-eight minutes left on a one-hour lifetime is as available to that removal as any other. The consequence for design is direct: - Any caller that reads an entry it wrote must handle the entry being absent, whatever the remaining lifetime said when it was written. - A deadline is not a guarantee that a multi-step flow which wrote something at step one will still find it at step three. - Lengthening a lifetime changes when time removes the entry. It does not make the entry survive pressure, and how a remaining lifetime figures into the store's choice of what to take, if at all, differs between stores. ## Surprise two: the entry with no lifetime This is the load-bearing variation, and it is the one an engineer who has only used one store will get wrong when they move. When the store needs room, **which entries are even candidates?** There are two real postures in this product class. | | Only entries carrying a lifetime are candidates | Every entry is a candidate | |---|---|---| | A permanent entry under pressure | untouched | at risk like any other entry | | What ever removes a permanent entry | nothing, until a caller deletes it or the tier is lost | the store, whenever it needs the room | | Characteristic failure | permanent entries accumulate, and entries that do carry a lifetime become the only ones ever taken | data the design assumed was resident quietly disappears | | What a design may lean on | the presence of permanent entries, at the cost of the above | nothing; every entry must be re-creatable | Both postures are defensible and both are shipped. The first protects deliberately permanent data at the cost of concentrating all pressure onto the entries with lifetimes - and if a keyspace reaches the point where nothing carries a lifetime, a candidate-restricted store has nothing it may take, and the pressure surfaces instead in whatever that store's behaviour at its ceiling is, which is a separate subject. The second treats the tier honestly as a space that can lose anything, which is simpler to reason about and unforgiving of any design that assumed otherwise. ## Designing when the posture is not yours to choose If the code will run against more than one store in this class - or against a hosted one whose posture may be set by someone else - the durable position is the intersection of the two: 1. Treat **every** entry as removable at any moment, whether or not it carries a lifetime. 2. Make each read path able to reconstruct or do without what it did not find, and make that path cheap enough to survive many entries going at once. 3. Attach a lifetime to anything that should not live forever, even when the store would eventually take it under pressure. Relying on pressure as a cleanup mechanism means cleanup happens only when the tier is already full. 4. Keep an eye on what is being written **without** a lifetime, because on a candidate-restricted store nothing at all will ever remove it. ## Finding out which posture you are on - Read what the store documents as eligible for removal under pressure, and whether that is a fixed behaviour or a configured one. - Confirm it rather than trusting the reading: on a scratch instance with a small ceiling, write only permanent entries until the ceiling is passed and see whether any of them disappear. If none do, the store is candidate-restricted and the pressure shows up some other way. - Repeat the check after an upgrade or a move to a managed offering, since this is precisely the kind of behaviour a different build or a provider default can change. The answer to record is not "entries without a lifetime are safe" or "entries without a lifetime go first". It is which of the two the tier in front of you does, and what your callers do when the answer turns out to be the other one.