An entry's deadline has passed but no caller has touched it since — by what routes does the store eventually reclaim its memory?

## Why there has to be a route at all The deadline changes what a reader is served and nothing else. It is not a scheduled job, and on a tier holding millions of entries it could not cheaply be one: waking at the right instant for every entry would mean maintaining, and constantly re-ordering, a structure over every deadline in the keyspace, and paying that cost on every write. So stores in this class defer the work and pick it up opportunistically. There are three occasions when it is cheap to do, and between them they are how memory actually comes back. ## The three routes 1. **Reclaim on access.** A caller asks for the entry. The read path has to compare the deadline before it can answer anyway, so when it finds a passed deadline it reports a miss and releases the entry in passing. This is free in the sense that the comparison was already being paid for. It fires only when someone actually asks, which is the whole of its limitation. 2. **The background sweep.** The store runs its own periodic pass over entries that carry a deadline and frees the dead ones it finds. The important property is that the pass is **best-effort**: it samples rather than enumerating the whole population, and it takes a bounded amount of work per cycle so that reclaim never starves request serving. A given dead entry can survive many cycles before a sample happens to land on it. 3. **Reclaim under allocation pressure.** The store needs room for a new write. An entry whose deadline has already passed is the cheapest possible thing to give up — nobody may be served it in any case — so it goes first. This is the route that eventually catches everything, but it only fires when the tier is under pressure, and it is not the same subject as forced removal of *live* entries at a memory ceiling. ## What varies between stores | route | what makes it fire | what it does not promise | |---|---|---| | reclaim on access | a caller asking for that entry | anything at all on a keyspace nobody reads | | the background sweep | the store's own timer, on stores that have one | that it visits every dead entry, or visits soon | | reclaim under allocation pressure | the store needing the room | anything until the tier is actually pressed | Do not assume one store's combination is the model. Some stores pair reclaim on access with a sampling sweep; some run a dedicated crawler thread; some have no background pass at all and return memory only when a reader arrives or when room is needed. What is common to all of them is the shape: **the deadline marks an entry dead, and a separate, later, opportunistic mechanism turns dead into free.** ## The consequence that matters in production Put the routes against a workload and the behaviour falls out: - **A keyspace that is read constantly** reclaims well. Most dead entries are touched soon after their deadline, so the first route does most of the work and the memory tracks the live set closely. - **A write-once keyspace nobody reads back** — audit records, fan-out state, anything written for a consumer that may never come — gets nothing from the first route. Memory comes back only as fast as the sweep samples, and, where there is no sweep, not until the tier is under pressure. - **A high write rate against a slow sweep** lets the dead population grow, because a sampled pass has no mechanism for going faster just because there is more to do beyond what its budget allows. ## How to reason about it in an interview Name all three routes, and then say what each one *cannot* do. That second half is what separates someone who has operated a tier from someone who has read a summary. The strongest form of the answer adds the thing none of the three provides: **no bound**. There is no setting that says "free the memory within one minute of the deadline", because every route is triggered by something outside the deadline's control — a caller, a timer with a budget, or scarcity. If your design needs the space back at a known time, the deadline is the wrong instrument, and an explicit pass that touches or removes the entries is the right one.