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

## What the read is for Reading an entry's **remaining lifetime** answers one question: how much of its lifetime is left before its **deadline** passes. Callers use it for a small number of honest purposes — deciding whether to refresh a value that is nearly finished, checking that a deadline the design requires is actually present, reporting how long a claim is still held, and diagnosing why something disappeared earlier than a team expected. What makes it an interview question is that the answer is not always a duration. ## The three shapes of an answer | Answer | What it means | What the caller should do | |---|---|---| | A duration | The entry exists and carries a deadline that has not passed | Act on the number, treating it as a snapshot | | No lifetime attached | The entry exists and is **permanent** — nothing will ever time it out | Attach a deadline if the design requires one | | No such entry | Nothing is stored under that name | Write the value again, or treat it as absent | The two non-durations are the whole content of the question. They look alike — neither is a number — and they mean opposite things. *No lifetime attached* says the data is fine and the deadline is missing. *No such entry* says the data is gone and there is nothing to attach a deadline to. A caller that treats both as "it is gone" will write a value that is already there, possibly clobbering a newer one. A caller that treats both as "it is there" will attach a deadline to nothing and believe it succeeded. Note also what *no such entry* does **not** tell you. It does not distinguish an entry that was never written from one whose deadline passed, and it does not distinguish either of those from an entry the store dropped for its own reasons. The read tells you the present, not the history. ## Telling them apart - **Where the store reports them distinctly**, the caller branches on the two answers directly. This is the clean case, and it is why a client wrapper should surface three outcomes rather than an optional number. - **Where the store, the client library, or a convenience wrapper collapses them** — mapping both to a null, an empty value, or a single "absent" case — the caller needs a second call, an existence check, to separate them. That second call is a different moment in time: between the two calls the entry may pass its deadline, be written, or be removed. The pair is not atomic, and a design that depends on it being atomic is relying on luck. - **Where the store exposes no such read at all** — several stores of this class do not — a caller that must answer the question carries the deadline inside the value it wrote and computes the remainder itself. That works for reporting and for refresh decisions, but it does not make the store enforce anything, and it does not tell you whether the store's own deadline is still there. ## The read is a snapshot, not a lock A returned duration was true when the store answered. By the time the caller acts on it, the deadline may have passed; another caller may have attached a new deadline, cleared the lifetime, or written a new value. This matters most in the pattern "read the remaining lifetime, and if it is short, do something about it": the entry can disappear between the decision and the action, so the action has to be written to be safe when the entry is no longer there — typically by making the follow-up write conditional on the entry's presence or by tolerating the case where it is absent. It matters again when the read is served by one copy of the tier and the write goes to another: the remaining lifetime you were told about is that copy's view. ## What varies between stores - Whether a read of the remaining lifetime exists at all. - Whether the two non-duration answers are reported distinctly or collapsed into one. - The resolution of the duration returned — some stores answer in whole seconds, some in finer units, and a caller that compares the answer against a sub-second budget is reading precision that is not there. - Whether the read is exact or best-effort on a copy of the tier, where the deadline was set on another node. ## The shape of a good answer Name the three outcomes, say the two non-durations mean opposite things and call for opposite repairs, describe how to separate them when the store or the library hides the difference, and finish on the snapshot property — that the number is already stale when you hold it. Do not describe the answers by whatever value a particular client returns for them; describe them by what they mean, because that is the part that transfers between stores.