How would you find out which entries in a running volatile tier could not be regenerated if it emptied?

## Why class by class, and not entry by entry A running tier holds far too many entries to reason about individually, and the property you are looking for is not a property of entries anyway — it is a property of the code that writes them. Two entries with adjacent keys can have completely different answers, while a million entries written by one function all share one. So the unit of the audit is the **entry class**: one writer, one naming scheme, one meaning. This matters because the usual failure of this audit is granularity. Asked "is the tier safe to lose?", people answer for the tier as a whole, and the tier as a whole is almost always a mixture. ## Getting the list of classes Two sources, in this order: 1. **The writers in the code.** Every place that puts something into the tier defines a class. This list is authoritative about intent, and it is the list you can keep current as the system changes. 2. **What is actually present in the tier**, as a cross-check. It regularly turns up classes the first list missed: a retired feature still writing, an operator's manual entries, a batch job, or another service that shares the tier and was never part of your review. (How you walk a live keyspace safely is its own subject; here the point is only that the two lists disagree, and the disagreement is the finding.) Where the two lists differ, the difference is the interesting part — not an error in the audit. ## The one question, and its three answers For each class, ask: **if this entry vanished between two requests, what produces the value again, and what does producing it cost?** | Answer | What the class actually is | What to do | |---|---|---| | A system of record produces it | A derived copy; the precondition holds | Record the rebuild cost and move on | | Nothing produces it | The tier is the sole home for that fact | Decide deliberately: give it a home, accept the loss, or remove the class | | Something produces a value, but not that value | The dangerous middle | Treat it as the second case until proven otherwise | The third row is the one that gets missed, because the review question is usually phrased as "is there a database behind this?" — which gets a yes, and stops the conversation one question early. ## What lives in the dangerous middle - **Accumulated values.** A counter or running total that grew inside the tier was never computed from stored state, so there is nothing to compute it from now. The source can tell you what it is today only if it independently recorded every increment, which is usually the very thing the tier was introduced to avoid. - **Derivations over inputs that have moved on.** The source rows still exist, so the review says derivable; but re-running the derivation today produces a different value, because the inputs changed, were corrected, or were deleted. If anyone acted on the old value, the new one is not a replacement. - **Values obtained from a third party.** Derivable, at a price — a rate limit, a per-call charge, or a contract that does not allow bulk re-fetching. Derivable once is not the same as derivable for every entry at once. - **Values that were expensive to produce the first time.** A derivation that takes minutes per entry is technically reconstructible and practically unavailable during an incident. - **Results of a non-repeatable decision.** Anything assigned rather than computed — an ordering chosen at write time, a randomised assignment, a generated identifier — cannot be regenerated, only invented again differently. ## Writing the answer down where it survives The output of this audit is not a verbal reassurance; it is a small table that lives with the design and is checked when a class is added: 1. **Entry class** — the naming scheme and what the entries mean. 2. **Writer** — the code path or the person that creates them. 3. **What regenerates it** — a named system of record, or the word nothing. 4. **Cost to regenerate** — per entry, and for the whole class at once. 5. **What is lost if it is not regenerated** — stated in terms a product owner recognises, not in terms of keys. A class whose third column is blank is the finding. Not a defect to fix on the spot — it may be an entirely legitimate use of the tier — but a decision somebody has to make on purpose, rather than a fact discovered during an incident. ## How this shows up in an interview The weak answer inspects the tier and reports what is in it. The strong answer says: I would list the writers, ask of each class what regenerates it and what that costs, cross-check against what is actually present, and expect the mixture — some genuinely derived, some with nothing behind them, and a third group that looks derivable until you ask whether re-deriving yields the same value.