What is a tombstone in Cassandra and why can tombstones cause problems?
Learn what a tombstone is in Cassandra, why deletes create them, how gc_grace_seconds and compaction work, and why too many tombstones slow or fail reads.
Expected Interview Answer
A tombstone is a special marker Cassandra writes to record that a row, column, or range of data has been deleted, rather than removing the data immediately. Because Cassandra uses append-only, immutable SSTables, deletes are recorded as new writes and the actual data is only purged during compaction after gc_grace_seconds.
Tombstones are essential for correctness in a distributed, eventually consistent system: they let a delete propagate to replicas that may have been down, preventing already-deleted data from resurrecting when a stale replica later serves a read. The trouble is that until compaction removes them, tombstones accumulate in SSTables, and a read that scans a partition must read through every tombstone in range. Large numbers of tombstones inflate read latency, consume heap, and can trip tombstone_warn_threshold or tombstone_failure_threshold, causing queries to fail outright.
- Makes deletes safe across replicas that were offline
- Prevents deleted data from resurrecting (zombie rows)
- Fits Cassandra's append-only, immutable SSTable model
- Removed automatically during compaction after gc_grace_seconds
- Supports range and TTL-based deletions, not just single rows
AI Mentor Explanation
Picture a scorer who never erases the scorebook. When a run is disallowed after review, they don't rub it out; they stamp a bright 'CANCELLED' note beside the entry so every scorer copying the book downstream knows to ignore it. If a scorer had stepped away, that stamp still tells them the truth when they return. But if hundreds of cancellations pile up, anyone tallying the innings must read past every stamp, and the tally slows to a crawl until the book is finally recopied clean.
Step-by-Step Explanation
Step 1
A delete arrives
A DELETE, column removal, TTL expiry, or range delete is issued against a partition.
Step 2
Write a tombstone
Cassandra appends a tombstone marker to the memtable and commit log instead of mutating existing SSTables.
Step 3
Replicate the marker
The tombstone propagates to replicas via the write path, hints, and read repair so all replicas agree the data is deleted.
Step 4
Wait out gc_grace_seconds
The tombstone is retained for gc_grace_seconds (default 864000 = 10 days) so slow or downed replicas can receive it before it is purged.
Step 5
Compaction purges
Once past gc_grace_seconds and no longer needed, compaction drops both the tombstone and the shadowed data, reclaiming space.
What Interviewer Expects
- Understanding that deletes are writes, not in-place removal
- Why immutable SSTables force the tombstone approach
- The role of gc_grace_seconds and compaction
- How tombstones prevent zombie/resurrected data
- How excessive tombstones hurt read latency and can fail queries
Common Mistakes
- Thinking a DELETE frees space immediately
- Lowering gc_grace_seconds without understanding resurrection risk
- Using queue-like patterns that generate huge tombstone ranges
- Ignoring tombstone_warn_threshold / failure_threshold warnings
- Confusing tombstones with TTL data itself rather than the delete marker
Best Answer (HR Friendly)
“A tombstone is a little marker Cassandra writes to say 'this data was deleted' instead of erasing it right away, which is needed so every copy of the data across the servers eventually agrees it is gone. The downside is that if too many of these markers pile up, reads have to wade through them and slow down or even fail until a cleanup process removes them.”
Code Example
-- Each of these writes a tombstone, not an in-place erase:
DELETE FROM users WHERE id = 42; -- row tombstone
DELETE email FROM users WHERE id = 42; -- cell tombstone
DELETE FROM events WHERE day = '2026-07-21'; -- range tombstone
-- TTLs also become tombstones when they expire:
INSERT INTO sessions (id, token) VALUES (7, 'abc') USING TTL 3600;
-- Tune how long tombstones survive before compaction can purge them
-- (shorter = reclaim sooner, but higher risk of deleted data resurrecting):
ALTER TABLE users WITH gc_grace_seconds = 259200; -- 3 daysFollow-up Questions
- What is gc_grace_seconds and what happens if you set it too low?
- How do range tombstones differ from cell tombstones?
- Why are queue-style data models an anti-pattern in Cassandra?
- How do tombstone_warn_threshold and tombstone_failure_threshold protect the cluster?
- How does compaction actually remove tombstones and shadowed data?
MCQ Practice
1. What does a Cassandra DELETE actually do to the data on disk?
SSTables are immutable, so a delete is recorded as a tombstone write; the shadowed data is removed only during a later compaction after gc_grace_seconds.
2. Why can too many tombstones cause read queries to fail?
Reads must traverse tombstones covering the requested range; crossing tombstone_failure_threshold aborts the query to protect the node.
3. What is the main risk of setting gc_grace_seconds too low?
If a downed replica rejoins after the tombstone is gone, its old copy of the data reappears as a zombie row.
Flash Cards
What is a tombstone? — A marker recording that data was deleted, written because SSTables are immutable; the data is purged later during compaction.
Why do tombstones exist? — To propagate deletes to all replicas (even downed ones) and prevent deleted data from resurrecting.
What is gc_grace_seconds? — How long a tombstone is kept (default 10 days) before compaction may purge it, giving replicas time to receive the delete.
How do tombstones hurt reads? — Reads scan through tombstones in range, inflating latency and possibly hitting tombstone_failure_threshold, which fails the query.
Common tombstone anti-pattern? — Queue-like models with frequent range deletes, which generate massive tombstone ranges.
Continue Learning
Related Interview Questions
What is read repair and how does anti-entropy work in Cassandra?
hard
What are hinted handoffs in Cassandra?
medium
Why do deletes make Cassandra reads slower, and how do you design around it?
hard
How do compaction strategies differ in write amplification and disk headroom, and how does that drive your choice?
hard