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?

## Where the cleanup obligation lives When an entry should stop being available after some period, somebody has to remove it, and there are only two candidates. Either the **application** remembers — a timer, a queued message, a scheduled sweep job, or a later request that deletes the entry by name — or the **store** does, because the write handed it a **lifetime** along with the value. In the second design the store records a **deadline** for that entry and stops serving it once the deadline has passed, without any further instruction from anyone. The important property is not that the second design is tidier. It is that the obligation now travels *with the data*. The entry carries its own end. Nothing about the writer's continued existence, its deployment, its queue or its code paths is load-bearing any more. ## The failure modes that separate the two designs An application-side delete is a second operation that has to happen later, and later is where things go wrong: - the process crashes between the write and the delete; - the instance is redeployed, scaled in, or rescheduled, and the in-memory timer dies with it; - the delete is on a conditional branch — an error path, a cancellation, a user action — and the condition never fires; - the entry's name was derived from state the caller no longer has, so nothing can name it to delete it; - the job that was supposed to sweep is disabled, throttled, or silently failing. Each of those leaves an entry with no lifetime that nothing will ever remove — a **permanent entry** created by accident rather than on purpose. A lifetime attached at write removes every one of those paths at once, because there is no later step to lose. | | Delete issued later by application code | Lifetime attached at write | |---|---|---| | Writer crashes after the write | entry stays indefinitely | stops being served at the deadline | | Instance redeployed or scaled in | timer lost with the process | unaffected — the store holds the deadline | | Delete branch never reached | entry stays indefinitely | stops being served at the deadline | | Needs the entry's name later | yes | no | | Costs an extra round trip later | yes | no | | Early removal still possible | yes | yes — an explicit delete still works | ## What the promise does and does not cover A candidate who has run one of these tiers is careful about the edges of the promise: 1. **It is a serving contract.** Once the deadline has passed a reader is not served the entry. That is the guarantee. 2. **It is not a reclamation schedule.** The memory is not handed back at the instant the deadline passes; when it actually comes back is a separate mechanism with its own timing. 3. **It is not durability.** An entry with no lifetime is *permanent* in the sense that nothing will time it out — not in the sense that it survives the store restarting. 4. **It is not erasure.** Nothing promises the bytes are overwritten when the deadline passes. 5. **It is not a capacity control.** A deadline says when the application stopped wanting the entry, not how much room the store has. ## What varies between stores This is the part a single-store engineer usually asserts wrongly, because the store they know has all of it: - **When a lifetime may be attached.** Some stores expose a standalone operation that puts a deadline on an entry that already exists; others accept a lifetime only as part of a write, and there the only way to change one is to write the value again. - **What form the deadline takes.** Some take a duration the store counts down; some also take an instant the caller computed, which puts the caller's clock in the loop. - **Whether it can be read back.** Reading the remaining lifetime of an entry is ordinary on some stores and simply absent on others. - **Whether it can be taken away.** Clearing the lifetime so an entry becomes permanent is an operation on some stores and not on others, where the equivalent is writing the value again with no lifetime. - **Granularity.** On most stores a deadline attaches to the addressable entry and nothing smaller; a design that wants a field of a structured value to end earlier has to give that field its own entry or carry the deadline inside the value and have every reader enforce it. ## How to answer this in an interview Say where the obligation lives, name two concrete ways the application-side version loses it, and then volunteer the boundary: the deadline governs what is served, not when the memory comes back, and stores differ in whether you can attach, read, extend or clear a deadline after the fact. That last sentence is what separates someone who has operated such a tier from someone who has read one product's documentation.