How does an entry with a fixed deadline behave differently from one with an idle deadline pushed forward by every access?

## Two shapes of one promise An entry's **lifetime** is a duration the store holds it for; the instant that duration ends is the **deadline**. Once the deadline passes, a reader is not served the entry any more — that is the whole of the promise the store makes, and it is the same promise in both shapes. This leaf is about one question asked after the deadline is first attached: **does anything move it?** - A **fixed deadline** is computed once, when the value is written, and never moves. The entry's total residency is bounded by construction: write plus lifetime, and that is the end of it. - An **idle deadline** is measured from the *last access* rather than from the write. Every access pushes it forward by a fresh lifetime, so the entry survives while it is in use and lapses only after a quiet stretch as long as the lifetime. The difference is not "short versus long". Two entries can carry the same lifetime and behave completely differently: under a fixed deadline the entry is gone at a predictable instant; under an idle deadline nobody can say in advance when it goes, because the answer depends on traffic that has not happened yet. ## What each shape is for | The question you are actually answering | Shape | Why it fits | |---|---|---| | "This must stop being served a known time after it was produced, however popular it is." | A fixed deadline | Residency is bounded by the clock, and traffic cannot extend it. | | "Keep what is in use, drop what has gone quiet." | An idle deadline | The deadline tracks the last access, so the population follows usage. | | "Both — keep it while it is in use, but never past a hard age." | An idle deadline with an absolute cap above it | The idle part reclaims quiet entries, the cap bounds total life. | Concretely: a derived copy of something another system owns wants its life bounded regardless of how often it is read, so it takes a fixed deadline. An in-progress basket a shopper keeps coming back to wants to survive while the shopper is active and to vanish when they walk away, so it takes an idle deadline. *How long* either window should be is a separate design question and not this one; the shape comes first. ## What each shape costs - A fixed deadline **removes entries that are in use**. A path that was warm a second ago takes a miss, and every consumer must handle that, because nothing about the entry being popular delays the removal. - An idle deadline makes the stored population **traffic-shaped rather than time-shaped**. You cannot bound how much is held from the lifetime alone; it depends on how many distinct entries are being touched inside the window. - An idle deadline **has no ceiling of its own**. An entry accessed more often than the lifetime is long never reaches its deadline at all, and can stay resident indefinitely while still looking, to anything that reads its remaining lifetime, like an ordinary entry that will expire soon. - An idle deadline is usually **not free**, because in most designs the caller, not the store, is what pushes the deadline forward. ## Who actually moves an idle deadline This is the part candidates skip. Many stores in this class do not move a deadline on a read at all; some offer refreshing on access as an option, and some offer a single call that reads the value and extends the deadline together. Where none of that is available, "idle" is not a setting — it is a behaviour the caller implements by issuing an additional write on every access. That turns a read-heavy path into a write-heavy one, which is a cost a design has to be willing to pay, and it is why "the store does not do this for me" is a legitimate answer rather than a mistake. ## Where designs genuinely differ - Whether a deadline can be attached or changed **after** the write, or only at write time. - Whether a read can extend a deadline at all, and whether that is on by default or something the caller requests. - Whether the deadline is given to the store as a **duration** it counts down or as an **instant** the caller computed — which decides whose clock matters. - Whether a store offers both an idle deadline and a hard maximum age; most do not, which is why the cap is generally the caller's job. ## Answering it in an interview 1. Name the measuring point: a fixed deadline is measured from the write, an idle deadline from the last access. 2. Map each to a workload in one sentence — bounded residency against reclaiming what has gone quiet. 3. Add the two consequences that show you have run one: a fixed deadline takes entries out from under live callers, and an idle deadline plus steady traffic is an entry with no end date.