skip to content

An entry under an idle deadline is read every few seconds and never disappears — how do you bound its total life?

level: seniorimportance: should knowfreq 50%

answer

  1. idleness is bounded, age is not
  2. busy entry never reaches its deadline
  3. remaining lifetime still looks healthy
  4. carry the creation instant with the value
  5. extend by the lesser of window and cap

basics

~20 s

Nothing bounds it unless you add one. An idle deadline restarts on every access, so steady traffic keeps the entry resident indefinitely; the fix is an absolute cap, usually carried by the caller as a creation instant checked before each extension.

solid answer

~50 s

An idle deadline only promises to remove entries that go quiet, and an entry read more often than its lifetime is long never goes quiet — so its total residency is unbounded, and nothing in the store flags it. This is not the same as an entry whose lifetime was cleared: this entry still carries a lifetime, and its remaining lifetime always reads as a healthy duration, which is why an audit for permanent entries misses it. Few stores offer both a moving deadline and a hard maximum age, so the **absolute cap** is normally the caller's: record the creation instant, compute the entry's age before each extension, and stop extending once the age reaches the cap — extending by the lesser of the idle window and the time left, so the last extension lands exactly on it. At the boundary, either let it lapse and reload, or rotate to a new name.

go deeper

for a junior

Hold on to one fact: an entry that keeps being accessed under a deadline measured from its last access does not go away. Silence removes it, not age.

for a middle

Explain why the store cannot help: it enforces the deadline it was given, and each access replaces that deadline, so nothing in the store tracks how old the entry is.

for a senior

Show the diagnosis and the repair: the entry whose remaining lifetime always reads fine and is months old, the creation instant you started carrying, and what you chose to do at the boundary.

for a principal

Set the rule for the tier. Decide which classes of state may be entrusted to a deadline that traffic can move, and make a maximum age part of the contract with consuming teams rather than an implementation detail.

## The entry that never goes quiet An idle deadline is a promise about *silence*: the entry goes when nothing has touched it for a whole lifetime. It is not a promise about age. If accesses keep arriving closer together than the lifetime, the deadline is pushed forward every time and the entry's total residency is bounded by nothing at all — not by the lifetime, not by the store, not by anything the design wrote down. For the busiest entries in the tier, which are precisely the ones a design most often puts on an idle deadline, "expires after ten minutes" can mean "has been resident since the service started". This matters whenever the value has an honest maximum age: a derived copy that must not be served past a certain age however popular it is, a value that must be reloaded after an upstream change eventually reaches it even if no invalidation ever arrives, or an entry holding a decision that must be re-made periodically. ## Why an audit does not find it It is worth separating this from the case it is constantly confused with. An entry whose lifetime was **cleared** is a permanent entry: it has no deadline, and an audit that looks for entries with no lifetime attached will find it. The entry described here is different in every observable way: - It **has** a lifetime, and always did. - Reading its remaining lifetime returns a perfectly ordinary duration — a few minutes, never anything alarming. - At every instant it is about to expire, and it never does. So the condition is invisible to exactly the check teams run for it. What finds it is a different question: *how old is the entry?* — which nothing answers unless the design recorded the answer. ## Building the cap yourself Most stores in this class give an entry one deadline, not two, so the cap is generally implemented by the caller: 1. **Record the creation instant** when the entry is first written — inside the value, alongside it under a companion name, or encoded in the entry's name. 2. **Compute the age** on each access: the current time minus the recorded creation instant. 3. **Decide before extending.** If the age has reached the cap, do not extend. If it has not, extend by the **smaller** of the idle window and the time remaining to the cap, so the last extension lands exactly on the cap instead of past it. 4. **Handle the boundary** deliberately rather than by accident (below). The recorded instant introduces the question of whose clock produced it; where writers and readers are different hosts, that is a real source of error, and the safe version compares two values produced by the same clock rather than mixing one host's timestamp with another's. ## What to do at the cap - **Let it lapse and reload.** The simplest: stop extending, the entry goes on its own, the next access takes a miss and rebuilds it. Every caller on the path must handle that miss, and if the entry is hot, several callers will take it together. - **Replace it proactively.** Rebuild the value and write it fresh with a new creation instant before the cap lands, so the path never takes a miss. More machinery, and worth it only where the miss is expensive. - **Rotate the name.** Make the entry's name carry the period it belongs to, so that at the boundary callers simply address a new entry and the old one lapses under its own idle deadline with nobody touching it. The cap becomes a naming decision rather than a check, at the cost of a name that changes over time. ## Where designs differ, and what to say about it Some stores can refresh a deadline on access themselves, some cannot; some expose an operation that extends a deadline without touching the value, some require a full rewrite; and a few systems built on top of a store do offer both an idle window and a maximum age as first-class settings. The portable statement is the one worth giving in an interview: **an idle deadline bounds idleness, not age, and any bound on age is something the design has to add** — either in the caller, or by choosing a store feature and accepting that the behaviour will have to be rebuilt if the tier ever moves. Say which of those you did and why, and name the boundary behaviour you chose, because "it lapses and everyone takes a miss at once" is a decision whether or not anybody made it deliberately.

  • Why does auditing for entries with no lifetime attached miss this case entirely?
    Because the entry has a lifetime. It is not a permanent entry in the store's sense — its deadline exists and keeps being moved. Reading its remaining lifetime returns a normal duration at every instant, so an audit for entries nothing will reclaim shows it as healthy. Only its age reveals it.
  • When you stop extending at the cap, why extend by the lesser of the idle window and the time left?
    So the final extension lands exactly on the cap rather than beyond it. Extending by a full window when less than a window remains would carry the entry past the maximum age you just decided to enforce, which defeats the cap on the very last access before it.
  • Is putting the cap in the entry's name instead of in the value a better choice?
    It trades a check for a naming rule. Callers addressing a period-stamped name automatically move to a fresh entry at the boundary, and the old one lapses untouched. The cost is that the name is no longer stable, so anything that must address the entry directly has to compute the same period.

saying these in an interview costs you the question

  • Assumes an idle deadline eventually removes every entry
  • Confuses this with an entry whose lifetime was cleared
  • Expects the store to enforce a maximum age by itself
  • Reads a healthy remaining lifetime as proof the entry is young
  • Extends by a full window even when the cap is closer