Deletion Horizon
also called Erasure Horizon, Last-Copy Latency
The elapsed time after an erasure request until the last copy of the record is gone or unreadable, set by the longest-lived derived copy rather than by the live database.
An erasure request deletes a row in seconds. The regulator's question is not about the row. It is about the last copy: the nightly backup, the warehouse time-travel snapshot, the search index, the quarterly extract in a shared drive, the processor who took a feed two years ago.
The deletion horizon is a maximum, not an average, and it is almost always set by a store nobody calls a database. Publishing the number, and the mechanism that makes it true, is what turns "we delete on request" from a claim into evidence.
Why it matters
Teams answer the regulator with the latency of the DELETE statement, which is both true and
irrelevant, and then discover during an audit that a restored backup resurrected the person. The
horizon is the honest commitment, and it is the only one you can defend with a schedule and a log.
It is also a design lever. Once the dominant term is visible — usually snapshot or backup retention — the organisation can decide, deliberately, whether 90 days of restore range is worth 90 days of horizon. That is a conversation about risk appetite, and it cannot happen while everyone believes deletion is instant.
Implementation patterns
- Enumerate every copy, then take the maximum. Live store, replicas, caches, search index, warehouse and its snapshots, event log, backups, analytics extracts, processors. The horizon is the largest of their retention or propagation times.
- Targeted deletes where they are cheap. A search index supports document deletion, so the index contributes minutes rather than a rebuild cycle of 7 days. Each targeted delete removes one term from the maximum.
- A suppression list, held outside the systems it protects, replayed by every restore, environment refresh and vendor re-import before the restored system takes traffic. This is the mechanism that lets you keep 35-day backups and still promise erasure.
- Crypto-shredding for stores you cannot rewrite. Encrypt per subject and destroy the key, which collapses the horizon of an append-only log to the key-destruction latency. Confirm your regulator treats unreadable as erased before relying on it.
- Automated processor instructions. A processor's clock starts when your instruction arrives, so the instruction is an API call, not a ticket raised on Friday.
Industry example
Published erasure commitments from large consumer platforms tend to read the same way: removal from systems serving the product within days, and removal from backups within the backup retention period, typically 30 to 90 days. That two-part shape is not evasion. It is the only accurate description of a system with backups, and it is what an architect should aim to be able to state with a number in 2026 as readily as an availability target.
Failure scenarios
- The silent resurrection. A restore returns erased rows, nothing errors, and the first evidence is a marketing email to someone who asked to be forgotten two years ago.
- The forgotten snapshot. Warehouse time travel keeps 90 days while everyone quotes the 35-day backup number, so the published horizon is wrong by two months.
- The suppression list inside the blast radius. It was backed up with the database it protects, so the restore brings back the data and an empty list.
- The processor nobody instructed. The contract says 30 days; nothing sends the instruction.
- Deletion without evidence. The rows are gone and no log proves it, which fails the audit as surely as not deleting.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Long backup and snapshot retention | Restore range, point-in-time recovery, analyst convenience | A long horizon you must publish and defend |
| Short retention plus suppression replay | A horizon measured in weeks | Less recovery range, and a restore path that must be tested with the filter in it |
| Crypto-shredding | Erasure inside immutable stores | Key management as a tier-1 concern, and a regulator who may not accept it |
When not to use it
If a dataset holds no personal data, it has no horizon and adding it to the inventory is busywork. The same applies to data held under a legal obligation that overrides erasure — regulated transaction records, for example — where the correct answer is the retention period and the obligation, not a deletion promise the law does not permit you to keep.
Interview question
Q: Your platform keeps daily backups for 35 days, warehouse snapshots for 90, a weekly search index rebuild, and feeds three processors. A regulator asks how quickly an erasure takes effect. What do you say, what would you change to halve the number, and what would that cost?
What a strong answer covers: the maximum-not-average framing · naming snapshots as the dominant term and proposing targeted deletion or shorter time travel · the suppression list as the mechanism that makes any answer survivable across restores · the automated processor instruction · and an explicit statement that the cost of a shorter horizon is recovery range, which is a business decision rather than an engineering one.
Quick check
Quiz: Backups are 35 days, warehouse snapshots 90 days, index rebuild weekly. What is the deletion horizon? About 90 days, set by the snapshots; the live delete is under a day and irrelevant to the answer.
Flashcard: What single mechanism keeps an erasure true after a restore? — A durable suppression list held outside the restored system and replayed before it takes traffic.