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?

## The deadline is a guess about a distribution A lifetime attached to an entry that guards work in progress encodes one number: how long the work is expected to take. The work itself is a distribution with a long tail — a slow dependency, a large input, a host under pressure — and the deadline does not move with it. Sized against the typical case, the deadline passes while the work is still running; sized against the worst case, the entry outlives a crashed holder by the same margin. That trade is the whole of this problem, and it is the mirror of the immortal entry: one bug leaves an entry that never goes, the other lets one go too soon. ## The two postures, and what each costs | posture | what it buys | what it costs | |---|---|---| | one long fixed deadline, no renewal | no moving parts, no background loop, nothing to fail | after a crash the entry sits untouched for the whole long lifetime | | short deadline plus renewal | the entry frees quickly when the holder dies | a loop that must keep running, and a stall that looks exactly like a crash | Neither is wrong. A short job whose worst case is seconds away from its typical case does not need a renewal loop; the machinery costs more than it saves. Work whose runtime spans orders of magnitude needs one. ## Renewal mechanics, in order 1. **Pick the period from the lifetime, not the other way round.** If the deadline is thirty seconds away and you renew every twenty-five, a single slow renewal ends the entry. A period several times shorter than the lifetime leaves room for a few failures before anything is lost. 2. **Observe the outcome of each renewal.** A renewal is a network write to the store and can be slow, fail, or be answered by a node that no longer holds the entry. Fire-and-forget renewal gives the holder a false belief with no way to notice it is false. 3. **Make the renewal conditional on the entry still being the one you created.** An unconditional write after the deadline has already passed either recreates an entry that nothing owns any more, or extends a deadline that now governs some other holder's entry. Where the store offers a compare-before-write form, or lets a small piece of logic run next to the data, the condition belongs there; where it does not, the design has to accept that the renewal can be wrong and say so. 4. **Put an absolute cap above the loop.** Renewal is a standing obligation, and an obligation with no ceiling means a wedged process that is no longer doing useful work can hold an entry indefinitely. The cap is the total life a renewal loop may extend an entry to, after which nothing pushes the deadline out further. 5. **Cancel deliberately at the end.** When the work finishes, remove the entry rather than letting the last renewal run down, so the next caller does not wait out a deadline for nothing. ## The stall that renewal cannot fix The case worth being honest about is the holder that is neither alive nor dead: a long pause in the runtime, a blocked call, a host that stops being scheduled. The renewal loop does not run, the deadline passes, and from the store's side that is indistinguishable from a crash — while the work is still running and will resume. **Renewal bounds this window; it never removes it.** Shortening the period narrows it, and every reduction costs another write per interval against the tier. No lifetime setting closes it, which is why the mechanics stop here and the question of what the work does when it resumes belongs elsewhere. ## Which clock, and which node Two details change the answer and must be stated rather than assumed: - **Was the lifetime given as a duration the store counts down, or as an instant the caller computed?** Only the second exposes the application host's clock to the problem; a skewed host computing an instant produces an entry that ends far too early or far too late, and the store has no way to know. - **Which node answered?** How a deadline behaves on a copy of the tier differs between stores: some copies enforce the deadline themselves, others wait to be told by the node that takes writes, so a read served by a copy can be answered with an entry whose deadline has already passed. A renewal design that reasons about a single clock on a single node is describing the simple case only. ## The interview answer Say the deadline is a guess about a distribution, offer both postures with their costs, give the period-to-lifetime ratio and the reason for it, insist on the conditional renewal and the absolute cap, and finish on the stall — that renewal narrows the window and cannot close it. That last sentence is what separates someone who has run this from someone who has configured it.