We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
2 system design questions lean on this idea. Each walks through the full answer.
System Design Masterclass · Database Fundamentals
Free preview: the first 2 parts of this 12-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Database Fundamentals
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You click "Delete" on an email. It vanishes from your inbox. Gone, right?
Not even close. Your email provider didn't actually remove that data. It left a marker behind, a gravestone of sorts, saying "this used to be here, but it's gone now." That marker is called a tombstone.
This might sound wasteful. Why not just erase the data immediately? Because in distributed systems, immediate deletion creates a nasty problem. If one server deletes a record and another server hasn't heard about it yet, the second server might think the record still exists. It might even replicate that "deleted" record back to the first server. The record comes back from the dead.
Tombstones prevent zombie data. They're not a workaround, they're a deliberate design choice used by Cassandra, DynamoDB, HBase, and dozens of other systems. Even PostgreSQL uses a form of tombstoning internally, marking rows as dead rather than removing them immediately.
A tombstone is a special marker that says: "a record used to exist here, and it was deleted at this timestamp."
Instead of physically removing data, the database writes a new record, the tombstone, that overrides the original. Any future reads see the tombstone and know to treat this key as deleted.
| Without Tombstones | With Tombstones |
|---|---|
| DELETE removes the row immediately | DELETE writes a tombstone marker |
| Other replicas don't know it's gone | Other replicas receive the tombstone during sync |
| Deleted data can reappear (zombie) | Tombstone prevents resurrection |
| Fast deletion, dangerous in distributed systems | Slightly more storage, safe in distributed systems |
The tombstone carries a timestamp. During , if a replica has the original record with timestamp T1 and receives a tombstone with timestamp T2 (where T2 > T1), it knows the delete happened after the write, so the delete wins.
This is a specific application of last-write-wins conflict resolution, which distributed databases rely on heavily.