a field guide to resurrected wordsentry № 014

tombstone

/ ˈtuːm·stoʊn /
noun · from tomb + stone — in computing, “a marker left where data was”

A marker left where data used to be, recording its deletion without removing it. The delete that doesn't.

meet the graveyard
exhibits

The Replicas

erase it on one node and a stale replica gossips it back. the dead do not stay dead for free.
DELETION
IS A WRITE
deletion holds
record live on every replica.
deletes issued: 0 · agree dead: 0/4zombie resurrections: 0

Four replicas hold the same row. Toggle tombstones off and press delete: the value vanishes on one node — but to a replica that never heard the news, an empty slot just looks like the oldest version of all, so it helpfully gossips the value back, and the record walks again. A delete that removes nothing is no delete. Toggle tombstones on and the delete instead writes something: a marker stamped with the newest timestamp that says this key is dead as of now. Being newest, it outranks the live value everywhere it spreads, and the row stays in its grave. Only later, once every replica has surely seen it, does compaction clear the marker. The headstone is not the absence. It is the durable, replicated announcement of it.

Lifeline of the Word

the literal
A tombstone marks where a thing is buried. The thing is still there.

Start with the honest object: a stone that records a name, a date, and the fact of an interment. It does not remove anyone. It marks the spot and insists you remember. Computing borrowed the word with its meaning fully intact — a marker that says gone, placed exactly where the thing remains.

distributed deletes
In a replicated system you cannot simply remove a row.

Delete a record on one node and the others, not yet told, may helpfully resurrect it from their copies. So instead of erasing, the system writes a tombstone: a marker recording deleted at time T, which propagates like any other write. Deletion becomes a thing you add, not a thing you take away.

CRDTs
A tombstone is how a delete survives a concurrent edit.

Conflict-free replicated data types keep tombstones so that removing an element cannot be silently undone by an edit happening elsewhere at the same time. The marker outlives the data precisely so the absence is itself a fact that can be merged. To forget reliably, you must first remember that you forgot.

Cassandra, DNS, AD
The marker lingers for a set lifetime, then maybe goes.

Cassandra tombstones haunt read performance until compaction clears them after a grace period. DNS has tombstone records; Active Directory has a tombstone lifetime measured in days. Across systems the pattern repeats: deleted objects do not vanish, they become markers with an expiry, waiting to be truly collected later — or never.

soft delete
Most apps never DROP anything. They set a flag.

deleted_at = now(). The row stays in the table; the interface simply stops showing it. Soft delete is the tombstone at application scale, chosen for undo, for audit, for safety — and it means the everyday verb delete almost never means what the user thinks. It means hide, and keep.

the right to be forgotten
Legal deletion and technical deletion are not the same delete.

GDPR grants a right to erasure, and it runs straight into tombstones, backups, replicas, and soft-delete flags scattered across systems designed never to truly remove anything. Making deletion mean deletion turns out to be one of the harder problems in modern data engineering, because the architecture was built to remember.

now
The deleted tweet, the unsent message, the emptied trash.

It is in the archive. It is in the logs. It is in a backup, a replica, a tombstone with a grace period that has not elapsed. Deletion is a promise the system makes to itself, and mostly keeps only in the interface. The graveyard grows; the count of things actually gone holds, as ever, at zero.