skip to content

Expiry Semantics

8 roadmaps21 questions

A lifetime attached to the entry and enforced by the store: what a deadline actually promises, when the memory comes back, and how an ordinary write makes an entry permanent.

on this pageshow

explore

questions

21

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

level: juniorimportance: must knowfreq 70%

answer

  1. two shapes, one promise
  2. measured from write, or from last access
  3. does traffic move the deadline?
  4. steady access means no end date
  5. an absolute cap sits above the idle one

basics

~20 s

A fixed deadline is set when the entry is written and never moves, so total life is bounded no matter how busy the entry is. An idle deadline is pushed forward by access, so it removes only entries that have gone quiet.

solid answer

~50 s

Both shapes end in the same event — the store stops serving the entry once the deadline passes — but they answer different questions. A **fixed deadline** is computed once at write time and never moves, so total residency is bounded by the clock whatever the traffic does; that is what you want when a value must not be served past a known age. An **idle deadline** is measured from the last access, so the entry survives while the gaps between accesses stay shorter than the lifetime and lapses only after a quiet stretch; that is what you want when the point is to drop what nobody is using. Two consequences follow: a fixed deadline can remove an entry that is in active use, and an idle deadline never removes an entry whose accesses stay closer together than the lifetime, so a busy entry can outlive its reason unless an absolute cap sits above it.

go deeper

for a junior

Recall the measuring point. A fixed deadline counts from the moment the value was written; an idle deadline counts from the last time anything touched the entry. Everything else follows from that one difference.

for a middle

Explain the mechanics: which workload each shape fits, and that an idle deadline usually means the caller issues an extra operation on every access rather than flipping a switch on the store.

for a senior

Show the failure you have seen: an entry under an idle deadline that steady traffic keeps resident forever while its remaining lifetime always reads healthy, and the absolute cap you added above it.

for a principal

Frame it as a contract. Decide which state in the tier may be entrusted to a moving deadline at all, and state the posture in terms that hold across stores that refresh on access and stores that never will.

## 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.

  • An entry must disappear a known time after it is produced, however often it is read. Which shape, and what breaks if you pick the other?
    A fixed deadline, measured from the write. With an idle deadline, steady reads keep pushing the deadline out, so the entry can outlive its intended age indefinitely — and the failure is silent, because the entry looks healthy and its remaining lifetime always reads as a comfortable duration.
  • Under an idle deadline, what does "the entry has gone quiet" actually mean?
    That one whole lifetime passed with no access. The deadline is measured from the last access, so the entry survives as long as consecutive accesses are closer together than the lifetime; a single gap longer than the lifetime is what ends it, not the total volume of traffic before or after.

A fixed deadline is a ticket stamped with the hour it stops being valid: it does not care how often you show it. An idle deadline is a storage unit the company clears out after a year with no visit — drop by every month and it is yours forever, which is why the contract also names a maximum term.

saying these in an interview costs you the question

  • Treats an idle deadline as simply a longer fixed one
  • Assumes every store pushes the deadline forward on a read
  • Says a read restarts the countdown on a fixed deadline
  • Believes a constantly read entry under an idle deadline expires anyway
  • Picks an idle deadline for data whose total age must be bounded
open as a page

An entry's deadline passed ten minutes ago and nothing has read it since — what does a reader get, and is the memory back?

level: juniorimportance: must knowfreq 68%

basics

~20 s

A 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.

open as a page

An entry written with a one-hour lifetime is missing ten minutes later - what else removes entries besides a deadline?

level: juniorimportance: must knowfreq 64%

basics

~20 s

Two different events remove entries. Expiry is removal the application asked for by attaching a lifetime; eviction is removal the store forced on it to free room. Only the second can take an entry early.

open as a page

A service needs an entry gone ten minutes after it is written. What does attaching a lifetime buy over deleting it later from application code?

level: juniorimportance: must knowfreq 72%

basics

~20 s

A lifetime attached at write makes cleanup the store's obligation: it stops serving the entry at the deadline even if the writing process crashes, is redeployed, or never reaches its delete path. Application-side deletion survives none of that.

open as a page

Your design wants an entry kept alive while it is being read — which side actually pushes the deadline forward, and what does that cost?

level: middleimportance: must knowfreq 60%

basics

~20 s

Usually the caller, not the store. Many stores do not move a deadline on a read, so an idle deadline is an extra write on every access, turning a read-heavy path into a write-heavy one.

open as a page

An entry carries a lifetime, and a caller now replaces its whole value with an ordinary write — what happens to the deadline?

level: middleimportance: must knowfreq 60%

basics

~20 s

Stores differ: an ordinary full replacement clears the entry's lifetime on some and leaves the deadline standing on others. A design assuming either silently produces permanent entries nothing reclaims, so pass the lifetime in the same write.

open as a page

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

level: middleimportance: must knowfreq 55%

basics

~20 s

Three routes: a caller touching the entry, a background sweep over entries that carry a deadline, and the store needing the room. Which of the three a store has, and how hard each works, varies between stores.

open as a page

A tier's count of deadline removals tripled this week while its forced-removal count stayed at zero - which number speaks to capacity?

level: middleimportance: must knowfreq 57%

basics

~20 s

Only the forced-removal count speaks to capacity. A tripled deadline count tracks write volume and lifetime length, not room; a forced-removal count above zero means the store could not fit a write without taking an entry away.

open as a page

A caller reads an entry's remaining lifetime and gets back no duration. Which two situations produce that, and how are they told apart?

level: middleimportance: should knowfreq 48%

basics

~20 s

Either the entry exists with no lifetime attached, or there is no such entry to answer for. Stores that distinguish them give two different non-duration answers; where they are collapsed, the caller needs a separate existence check, which races.

open as a page

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%

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.

open as a page

When does it matter whether a deadline was sent as a duration the store counts down or as an instant the caller computed?

level: seniorimportance: should knowfreq 45%

basics

~20 s

It matters as soon as clocks disagree. A duration is counted down on the store's clock; an instant the caller computed is only as good as that caller's clock, so skew makes the entry lapse early or late.

open as a page

An entry's deadline is meant to outlast a job but passes while the job still runs — how should the lifetime be sized and renewed?

level: seniorimportance: should knowfreq 50%

basics

~20 s

Size the lifetime against the worst plausible runtime, or keep it short and renew on a period several times smaller, so failed renewals still leave attempts before the deadline. Renewal is a standing obligation with an absolute cap.

open as a page

An entry with a lifetime is changed in place — one field updated, a stored number incremented, a collection grown — what happens to its deadline?

level: seniorimportance: should knowfreq 44%

basics

~20 s

On stores that understand structure, an in-place change commonly leaves an existing deadline standing and attaches none when it creates the entry. Counters and collections are usually born permanent, because the creating operation carries no lifetime.

open as a page

A team plans to start cleanup work the moment an entry's deadline passes by subscribing to the store's expiry announcements — what will they hit?

level: seniorimportance: should knowfreq 42%

basics

~20 s

Announcements fire when the entry is reclaimed, not when its deadline passes, so they arrive late by an unbounded amount. Where a store emits them at all they are best-effort, so a listener that is disconnected simply misses them.

open as a page

Every entry on your tier is written with a lifetime, yet its reported memory keeps climbing — what explains that, and what would you check?

level: seniorimportance: should knowfreq 50%

basics

~20 s

Most likely the tier holds entries whose deadlines passed but which nothing has reclaimed: nobody reads them back, and a sampled sweep is not keeping up. Check whether anything reads, and whether memory falls under pressure.

open as a page

Under memory pressure, may a store remove an entry whose deadline has not arrived, or one carrying no lifetime at all?

level: seniorimportance: should knowfreq 49%

basics

~20 s

Yes to the first: a deadline promises when the store stops serving an entry, not that the entry lasts that long. The second varies by store - some treat only entries carrying a lifetime as candidates, others the whole keyspace.

open as a page

A read your service expected to hit returns nothing - how do you decide whether it expired or was forced out, and what changes next?

level: seniorimportance: should knowfreq 54%

basics

~20 s

A read that finds nothing carries no reason, so the verdict is indirect: the entry's age against the lifetime it was given, the tier's forced-removal count over the same window, and whether unrelated entries went at once.

open as a page

Your store accepts a lifetime only alongside a write, and the entries already hold values you must not lose. How do you give them a deadline?

level: seniorimportance: should knowfreq 40%

basics

~20 s

Write the value again with a lifetime — that costs a read first and can replace a concurrent update. Or carry the deadline inside the value, which readers must enforce. The repair that lasts is making every write carry its deadline.

open as a page

A shared in-memory tier keeps growing and holds many entries with no lifetime attached — what audit and what contract do you put in place?

level: principalimportance: should knowfreq 36%

basics

~20 s

Measure the share of entries with no lifetime attached per namespace and trend it, rather than counting once. Then make it a contract: each namespace declares its posture, permanent ones need an owner and a deletion path.

open as a page

One service must run against two in-memory stores whose lifetime handling differs, one taking a deadline only at write. How do you design the expiry handling once?

level: principalimportance: should knowfreq 34%

basics

~20 s

Design from the intersection: a lifetime attached at write is the floor both stores share, and every other operation goes behind one narrow interface with per-store fallbacks. Decide once whether callers send a duration or a computed instant.

open as a page

A batch load writes ten million entries with the same lifetime, so every deadline lands in the same second — what happens inside the store?

level: seniorimportance: nice to knowfreq 38%

basics

~10 s

At that second, ten million entries stop being servable and nothing else happens. The reclaim work appears at once but drains gradually, so memory slopes down - or stays flat if nothing reads them.

open as a page