The Right to Disappear

What is broken

Most systems do not delete. They set a flag. The row stays where it was, with the payload intact, and every query learns to look away. The interface says the account is gone; the database says the account is sleeping. The difference is invisible to the person who asked and obvious to anyone with a backup, a replica, an analytics export or a read-only support login.

The flag then leaks. A join ignores it, a nightly job resurrects the record, a search index still returns the name, a queue redelivers the message, a feature table keeps the embedding. Deletion becomes a rumour that each service has to be told about separately, and no one owns the telling. When a person asks whether they are really gone, the honest answer is usually that we do not know.

None of this is malice. It is architecture. Deletion was treated as a state of a row rather than an event in a system, so no one had to design propagation, proof or absence. The boolean was cheap. The fact is expensive. That is precisely why it has to be specified.

What the requirement would take to build

Deletion has to be an operation with an owner, a route and a receipt. The first requirement is a tombstone: a record that something existed and was removed, carrying the identifier and the time but none of the payload. The tombstone is what other systems read. It says gone, and it cannot be joined back into a person.

The second is propagation. A real deletion plan names every store that has ever held a copy: the primary database, replicas, the search index, caches, object storage, queues, analytics, exports and any model feature store. Each one gets a route, a deadline and a test that asserts absence rather than intent. Backups are not exempt; their retention is a limit that the deletion promise has to fit inside.

The third is proof. A person should receive a deletion receipt: what was removed, when, from which systems, and what remains for legal or safety reasons. That receipt has to be generated from the same machinery that performs the work, not typed by support.

The fourth is that absence must be readable. A deleted profile should return gone from a read API, not a flag that every consumer is trusted to interpret. Where a payload must disappear before a backup expires, crypto-shredding — deleting the key rather than every ciphertext — can turn an unwinnable chase into a bounded one.

The test is simple and uncomfortable: can the company prove, on demand, that a person is not in the system? If the answer depends on a dashboard or a careful human, deletion is still a boolean.