In a persisted document registry, how do you decide when an old operation entry is safe to delete?

## Deleting an entry is a client-breaking change with no roll-forward Everything that makes a late-published manifest painful makes a prematurely deleted entry worse. The failure is identical — an identifier the server cannot resolve, every request from that build failing, no text to fall back on — but the usual fix is unavailable: the client is already installed, already offline, already in a warehouse. Restoring the entry is the real remedy, and it only starts once somebody notices. So "when can this row go?" is not a housekeeping question. It is "can anything still send this key?", and the registry has to be built to answer it. ## Collect the evidence at lookup time The only place that knows an identifier is still alive is the lookup path. Record, on every resolution: the identifier, the timestamp, whether it was found, and — the part people leave out — **which client release sent it**. A build already knows its own version; pass it in a request header, or namespace the identifiers by release. Without it you learn that something still uses an entry but not what, which tells you nothing about whether that something can be upgraded. With that data the registry becomes a set of entries tagged by the release that introduced them and by the releases still calling them, and a retention policy can be written in terms of releases rather than dates. ## The policy Retain the union of the manifests for every client release at or above a **supported floor**, and consider an entry for removal only when it is below the floor *and* has gone unused for longer than the worst realistic gap between one client's uses. That second clause is where purely time-based retention fails. A warehouse handheld on a freight-tracking graph may scan all day for three weeks and then sit in a charging cradle in a depot for a month; a driver's device syncs when it finds signal. Thirty days of silence from such a fleet is not evidence of death, it is evidence of a quiet month. Any window you pick has to be longer than the longest legitimate quiet period, which for installed software is measured in months. The floor itself only means something if the client enforces it. An app that checks a minimum supported build at launch and blocks below it makes the floor real; without that, the floor is whatever the slowest user in the field does, and the retained set only grows. That is a product decision as much as a platform one, and naming it is what separates a senior answer from a principal one: you are choosing between registry growth and upgrade friction, and calling the choice technical does not make it go away. ## Delete in two stages Withdraw before you remove. Mark the entry withdrawn but keep serving it, and alert on every hit with the release that sent it. A quiet period in that state is far better evidence than a quiet period in a usage log, because it is measured against a decision you have already made and are actively watching. Hard-delete only once a withdrawn entry has gone untouched across a full sync cycle for the slowest client you support. Do it in batches you can undo. Keeping the withdrawn text somewhere restorable means a mistake costs a re-publish rather than an emergency rebuild of an old client. ## Bias toward keeping — but know the real cost A registry entry is a few kilobytes of query text and an index row. Eight thousand four hundred of them, accumulated over a couple of years of releases, is a rounding error in storage and no measurable difference in lookup time. Anyone who justifies deletion by registry size has not measured it. The costs that are real are subtler. Retained documents **pin the schema surface they select**: a field no current build asks for still has live callers for as long as an old build's document is registered and reachable, so the retention set quietly constrains what you can change. And per-operation dashboards fill with entries nothing shipped uses, which makes usage data harder to read at exactly the moment you want to read it. Both argue for deleting eventually and deliberately — with a supported floor, evidence from the lookup path, and a withdrawn state in between — rather than either purging on a schedule or never touching the registry at all. "We never delete, and here is why" is a defensible interim position. "We delete after 90 days", with no idea who is still calling, is the answer that gets marked down.