An entry's deadline passed ten minutes ago and nothing has read it since — what does a reader get, and is the memory back?
answer
- two clocks, not one
- serving contract, not a schedule
- invisible to readers immediately
- bytes return on touch, sweep or pressure
basics
~20 sA reader is served nothing: past its deadline the entry is never handed back. The memory is usually still held — stores free an expired entry when something touches it, a sweep reaches it, or the room is needed.
solid answer
~50 sTwo promises are involved and only one of them is exact. The deadline is a serving contract: once it passes, the store stops handing that entry to any caller, so a read looks like a miss and stays that way. The deadline is not a reclamation schedule — nothing runs at that instant to free the bytes. The memory comes back later, by one of three routes: a caller touches the entry and the store notices it is past its deadline, the store's own background sweep happens to reach it, or the store needs the room for something else. Stores in this class differ in which routes they have and how hard each one works, but none of them returns memory at the instant the deadline passes. So after ten minutes with no reader, the value is invisible and its bytes are very likely still counted.
go deeper
Recall the split: the deadline decides what a reader is served, not when memory is freed. An entry past its deadline is never handed back, but it may still be occupying space.
Explain the mechanics. The read path compares the deadline and reports a miss, while the freeing is done by a separate route — a caller touching the entry, a background sweep, or the store needing the room.
Show you have seen the consequence in production: reported memory that stays high long after the deadlines passed, on a workload that writes entries nobody reads back.
The argument to make is that a deadline is not capacity management. If a sizing model assumes memory returns on schedule, the design carries an unfunded assumption that surfaces only under load.
## The word "expiry" fuses two events Attaching a **lifetime** to an entry buys one exact promise from the store: once the **deadline** has passed, no caller is served that entry. A read comes back as though nothing is stored under that key. That guarantee is crisp, and it is the only crisp part of expiry. What the promise says nothing about is when the memory the entry occupies is returned to the store. The moment a reader stops being served the entry and the moment the bytes come back are **two different events**, and the gap between them is not bounded by the lifetime you chose. An entry given a ten-second lifetime can be invisible to every caller from the tenth second onward and still be occupying every byte it occupied at the first second — for minutes, or for days. ## What a reader observes On stores in this class that implement lifetimes, the deadline is checked on the path that answers the read. Before handing back a value the store compares the entry's deadline against the current time, and if the deadline has passed it answers as a miss. Two consequences follow: - **Expiry never shows up as stale data.** You cannot read an entry whose deadline has passed, however long the store has failed to get around to freeing it. The delay is a memory story, never a correctness story for the reader. - **Application code does not need its own deadline check.** The store enforces the lifetime; comparing a timestamp you stored inside the value is solving a problem the store already solved, though teams sometimes do it deliberately for other reasons, such as wanting a value to outlive its own freshness. ## What the memory shows At the deadline, nothing happens to the bytes. No work is scheduled, no callback fires, and the store's reported memory does not move. The entry becomes **dead** — unservable but still resident — and it stays that way until something reclaims it. | moment | what a reader is served | what the store's memory figures include | |---|---|---| | before the deadline | the value | the entry | | the instant the deadline passes | nothing | the entry, unchanged | | once something reclaims it | nothing | the entry is gone | The third row has no time attached to it on purpose. How long it takes is a property of the workload and of the store, not of the lifetime you set. ## The three routes by which the bytes come back 1. **Reclaim on access.** A caller asks for the entry, the read path finds a passed deadline, and the store releases it then. The caller is told there is no entry; the freeing is a side effect of the failed read. 2. **The background sweep.** Many stores run a periodic pass over entries that carry a deadline and release the dead ones. That pass is deliberately **best-effort and sampled** rather than an exhaustive walk, because it competes for the same machine that is answering requests. 3. **Reclaim under allocation pressure.** When the store needs room, an entry already past its deadline is the cheapest thing to release, so it goes. This is not the same as forced removal of live entries under a memory ceiling — that is a different subject, and it acts on entries whose deadlines have not passed. ## Where stores differ, and where they do not What varies is which of the three routes a store has and how aggressively it runs them. Some stores have no background pass at all and rely entirely on a reader arriving or on needing the room; others run a pass whose pace is tuned so that reclaim work never starves request serving. A store that reclaims eagerly still does not reclaim instantly. What does **not** vary across this class is the shape of the thing: the deadline governs what a reader is served, and the memory returns on a separate, later schedule. That is the sentence worth carrying into an interview, because it is true of every store of this kind, and the specific reclaim machinery is different in each one. ## What follows for a design - **Never size a tier on the assumption that memory comes back on time.** The headroom you need covers the live entries plus however many dead ones happen to be resident. - **A deadline is not a capacity mechanism.** It expresses when an entry stops being meaningful, not when the store gets its room back. - **A workload that writes entries nobody ever reads back gets no help from the first route at all**, so on such a keyspace the memory behaves very differently from one that is read constantly. - **Shortening the lifetime does not make the memory return sooner** on a keyspace nothing reads; it only makes the entries dead sooner, and dead entries still occupy space.
- If nothing frees the entry at the deadline, could a caller still be served the old value?No. The deadline is checked on the read path, so an entry past its deadline is reported as absent even while its bytes are resident. The delay only ever affects memory accounting, never what a reader sees. That separation is what makes the late reclaim tolerable: you pay for it in space, not in correctness.
- Does it cost a caller anything to read an entry whose deadline has passed?The read itself is an ordinary lookup that ends in a miss. On stores that reclaim on access, that caller's read is also what releases the entry, so the freeing is done on its behalf. For a very large value, stores differ over whether the release happens inline on that call or is handed to a helper so the caller is not held.
A hotel checkout time. At eleven the room stops being yours and the front desk will not let you back in — that part is exact. The room is not back in inventory at eleven, though: it returns when housekeeping gets to it, when someone asks for that specific room, or when the hotel is full and needs it. The deadline governs access; the cleaning schedule governs supply.
saying these in an interview costs you the question
- Says the entry is deleted at the exact instant its deadline passes.
- Expects the store's reported memory to fall as deadlines pass.
- Thinks a reader can still be served an entry until it is reclaimed.
- Believes application code must compare the deadline itself on every read.
- Assumes every store runs a background pass that clears deadlines promptly.