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

## A miss carries no reason On stores of this class, a read that finds nothing returns the same answer whether the deadline passed, the store took the entry for room, another caller deleted it, or it was never written. The entry is gone, so there is nothing left to inspect: a caller can ask for an entry's **remaining lifetime** while the entry exists, but after it is gone there is no record to read. Every diagnosis here is therefore circumstantial, and the skill is knowing which circumstances actually discriminate. ## The evidence that discriminates 1. **The arithmetic on the entry itself.** How old was the entry, and what lifetime was it written with? If its age exceeds the lifetime, expiry is a sufficient explanation and no capacity story is needed for this entry. If it was comfortably inside, expiry is ruled out and something else took it. 2. **The tier's forced-removal count across the same window.** If the store never had to make room during the window, it forced nothing out, and pressure is excluded - provided the counter covers the window and the node that served the read. If it moved, pressure becomes a live candidate for the entry in question, although it does not prove this particular entry was one of the ones taken. 3. **The shape of the loss.** Entries reach their deadlines scattered according to when they were written and how long a lifetime each got, so ordinary expiry looks like a steady trickle. A bout of pressure tends to look like a burst - several unrelated entries, written at different times with different lifetimes, all missing across the same short interval. 4. **An announcement, where the store emits one.** Some stores can emit a message when an entry is reclaimed. Treat a received announcement as evidence, and treat silence as nothing at all: the emission is best-effort, it happens when the reclaim happens rather than when the deadline passed, and not every store has the feature. 5. **What the write actually did.** Confirm the write succeeded, went to the key the reader is asking for, and carried the lifetime it was supposed to carry. A surprising share of these investigations end here. ## Removals that are neither Before reaching for either verdict, exclude the causes that are not removals by the store at all: - an explicit delete by another caller or an operator; - a write that failed, or that landed under a different key than the read constructs; - a restart of the node, which for a volatile tier may mean it came back empty; - a read served by a copy of the tier that has not received the write yet; - an entry whose value was replaced by a write that also reset or cleared its lifetime, so it went earlier or later than expected. ## What each verdict changes | Verdict | What it means | What you do next | |---|---|---| | Expiry | The application asked for this removal, and got it | Re-examine whether the lifetime matches the access pattern, and whether the caller assumed a deadline moves on access when the store does not move it | | Forced removal | The store could not fit a write and chose an entry to give up | Ask what is live at once against how much the tier holds, and re-examine any correctness that assumed an entry would still be there | | Neither | Nothing was removed on the store's initiative | Look at the write path, the key construction, the restart history, and which copy answered the read | The distinction earns its keep in the second row. A forced removal is not only a capacity fact; it invalidates an assumption. Any flow that wrote something and expected to find it later must now be read as a flow that can find nothing, and that is usually a bigger finding than the missing entry that started the investigation. ## Where the evidence is weak Be honest about the limits of this diagnosis, because they are what separate a useful verdict from a confident wrong one: - **Counters differ.** Stores book an entry that was already past its deadline when the room was needed under different names, so the two counts are not always cleanly disjoint. - **Announcements are unreliable by design.** They are best-effort and late relative to the deadline, so they can confirm a removal but never rule one out. - **The window may not line up.** A counter read per node, or aggregated over an interval longer than the incident, can hide exactly the movement you are looking for. - **Both can be true.** An entry can be past its deadline *and* the tier can be under pressure. In that case time is a sufficient explanation for the entry, while the pressure remains a separate finding about the tier that is worth its own follow-up. The strongest version of the answer in an interview is usually the honest one: state the evidence you would gather, state which conclusion each piece supports, and say plainly that a miss on its own supports none of them.