When a store removes entries at its memory ceiling, what does restricting removal to entries that carry a lifetime buy, and how does it fail?
answer
- two axes, not one
- which entries may go at all
- a deadline reads as consent
- eligibility can run out
- empty candidate set at the ceiling
basics
~20 sRestricting eviction to entries that carry a lifetime protects entries nobody marked as disposable, so state with no other copy survives memory pressure. It fails when nothing eligible remains: the store cannot free memory and writes needing it start failing.
solid answer
~50 sAn eviction policy is two independent decisions, not one. The first is the order removal happens in — by recency, by frequency, by remaining lifetime, or at random. The second is eligibility: whether any entry in the keyspace may go (whole-keyspace removal), or only entries that carry a lifetime (lifetime-only removal). The restriction turns an ordinary write into a declaration: attaching a deadline reads as `this entry is expendable`, and an entry written without one stays permanent under pressure. On a tier holding sessions, locks or counters that exist nowhere else, that is the safer default, because the entries nobody marked as disposable cannot be silently destroyed. Its failure mode is eligibility exhaustion: if every remaining entry is permanent, there is no candidate, and at the ceiling the store behaves as though it had no removal policy at all. Stores differ in which axes they expose and in their defaults.
go deeper
Remember the shape: when memory runs out, a store either refuses the write or takes an entry away, and taking away an entry that exists nowhere else is data loss rather than a miss you can re-read.
Explain both axes in one breath: the order removal happens in, and which entries are eligible for it at all. Say what attaching a lifetime implies under lifetime-only removal, and name the case where nothing is eligible.
Show you have watched the eligible share, not just memory. Describe how a release that stops attaching deadlines turns a healthy tier into one that cannot free anything, and what you would alert on before the ceiling.
Frame eligibility as where the risk decision belongs: with the code that knows what an entry is, or with whoever configured the store. Argue which populations should be permanent, and accept the failed writes that follows.
## Two decisions wearing one name An **eviction policy** is the rule a store applies when a write needs memory and the store has reached its **memory ceiling**. It is usually described as a single choice, but it is two independent ones: - **Order** — among the entries that may be removed, which one goes first: the entry untouched for longest (the recency family), the entry accessed least (the frequency family), the entry whose remaining lifetime is shortest (the lifetime-ordered family), or an arbitrary one (random removal). - **Eligibility** — which entries may be removed at all: any entry in the keyspace (**whole-keyspace removal**), or only entries that carry a lifetime (**lifetime-only removal**). Most candidates answer entirely on the first axis and never mention the second. The second is the axis that decides whether memory pressure can quietly destroy data. ## What the restriction actually says An entry carries a lifetime when whoever wrote it attached a deadline to it. Under lifetime-only removal, the store reads that deadline as a second statement the writer may not have intended to make: *this entry is expendable*. An entry written with no lifetime is permanent, and its permanence is enforced against memory pressure as well — it is never a candidate, however cold it is and however large it has grown. That is useful precisely because it moves the decision. The code that wrote the entry knows what the entry is; the configuration that set the policy does not. ## What it buys - Anything written without a deadline survives the ceiling. On a tier holding sessions, leases, quota counters or deduplication records — state with no source of truth to re-read — that is the difference between a slow tier and a wrong one. - The blast radius of eviction becomes a property of each write rather than a single global posture applied to every population in the keyspace. - It converts a silent outcome into a visible one. An entry vanishing is invisible until something reads it; a write that cannot be served is immediately visible to the caller and to monitoring. ## How it fails 1. **Eligibility runs out.** If every remaining entry is permanent, the candidate set is empty. The store cannot free anything, so at the ceiling it behaves exactly like a store with no removal policy: writes needing memory fail while reads keep being served. The restriction did not remove the pressure, it changed what the pressure does. 2. **It still loses data.** A lifetime is not a statement that the entry is worthless. A lease or a deduplication record normally carries one and is irreplaceable while it lives. Lifetime-only removal narrows the population at risk; it does not make removal safe. 3. **It concentrates the damage.** All pressure lands on entries that carry lifetimes, so the first casualties are exactly the entries the application marked as time-bounded — and they are removed *before* their deadline, which is a different event from reaching it. 4. **The eligible share is invisible unless you watch it.** A tier can run for months with a healthy pool of expendable entries and then drift permanent-heavy after one release that stops attaching deadlines. ## Removal under pressure is not removal by deadline Both take entries away and they are different mechanisms with different triggers. Removal because a deadline passed is **expiry**: it happens whether or not memory is tight. **Eviction** is removal because the ceiling was reached, and it takes entries whose deadlines have not passed. Lifetime-only removal is where the two vocabularies touch — the criterion mentions a lifetime, the trigger is still the ceiling. | | whole-keyspace removal | lifetime-only removal | |---|---|---| | candidate set | every entry | only entries carrying a lifetime | | what an ordinary write means | nothing extra | the entry is permanent | | worst case | irreplaceable state disappears silently | no candidate exists; writes needing memory fail | | who decides the risk | whoever configured the store | whoever wrote the entry | ## Where implementations differ - Some stores expose both axes as configuration; some only ever remove entries that carry a lifetime; some remove any entry and offer no choice; some have no ceiling concept at all, in which case the machine, not a policy, decides what dies. - Where a choice exists, the **default** differs. A store that refuses writes by default and a store that removes by default behave completely differently under the same workload with no configuration touched. - Even under whole-keyspace removal the candidate set may not be the whole keyspace: a store that allocates from fixed-size blocks looks for a victim among entries occupying the block size it needs. Because of that spread, the answer that survives scrutiny names both axes and then says which posture *this* store is on, instead of presenting one product's default as the behaviour of in-memory stores. ## What an interviewer is listening for That you separate order from eligibility; that you can say why a tier holding state with no other copy prefers the restriction; and that you treat the restriction as a trade with its own failure mode rather than as free safety.
- Why can lifetime-only removal still lose data?Because a lifetime marks an expected end, not worthlessness. A lease, a deduplication record or a partially built aggregate usually carries one and is irreplaceable while it lives. Under pressure the store takes it before its deadline, which is data loss with no source to re-read. The restriction narrows who is at risk; it does not make removal harmless.
- What happens when the ceiling is reached and no entry is eligible?Nothing can be freed. The store has a removal policy that cannot fire, so writes that need memory fail while reads continue to be served from what is already resident. The symptom looks like a store configured never to remove anything, which is why the eligible share, not just the memory number, belongs on a dashboard.
- How would you stop the eligible pool from emptying?Attach lifetimes deliberately to the populations you are willing to lose, rather than leaving them off by accident, and track the share of resident entries that carry one over time. Alert when that share falls or when removals stop happening while memory keeps climbing, because both mean the ceiling will next appear as failed writes.
saying these in an interview costs you the question
- Assumes every entry in the keyspace is removable at the ceiling.
- Thinks a lifetime only drives expiry and never eligibility.
- Believes lifetime-only removal makes data loss impossible.
- Says the store removes something anyway when nothing is eligible.
- Treats the removal order as the entire policy.
- Asserts one store's default eligibility rule as how stores behave.