Cassandra Write Path & Tombstone Gotchas

Scenario context

Cassandra turns deletes into special markers called tombstones. Excessive deletes lead to heavy tombstone scanning and GC stalls during reads. In Apache Cassandra, write operations avoid expensive random disk I/O by executing sequential appends. When a mutation is executed, Cassandra appends the mutation to a sequential CommitLog on disk for immediate durability and writes the updated row into an in-memory sorte…

This walkthrough focuses on Visualizing the Gotcha.

Before making a design choice, clarify:

• In Apache Cassandra, write operations avoid expensive random disk I/O by executing sequential appends.
• When a mutation is executed, Cassandra appends the mutation to a sequential CommitLog on disk for immediate durability and writes the updated row into an in-memory sorted structure known as a Memtable .
• When the Memtable reaches capacity or age limits, Cassandra flushes its sorted contents directly to immutable disk files called SSTables (Sorted String Tables) .

Concepts in play: btree-vs-lsmtree, tree-data-structures, jvm-internals-and-garbage-collection, caching

Stage 1 — The Solution & Trade-offs

• When a read query executes, the Cassandra coordinator must scan across multiple SSTables on disk and merge the latest values while filtering out tombstoned entries: - The Tombstone Pitfall : If your workload generates f…
• This causes sudden CPU spikes, triggers TombstoneOverloadedException , and causes severe JVM stop-the-world garbage collection pauses.
• • Best Practice Solution : Avoid database anti-patterns that rely on frequent single-row updates or deletes.
• For time-series telemetry or logging workloads with automatic expiration, configure TimeWindowCompactionStrategy (TWCS) so entire SSTable files drop cleanly when their window expires without triggering tombstone scans.

Observable outcome: For time-series telemetry or logging workloads with automatic expiration, configure TimeWindowCompactionStrategy (TWCS) so entire SSTable files drop cleanly when their window expires without triggering tombstone scans.

End-to-end outcome

In Apache Cassandra, write operations avoid expensive random disk I/O by executing sequential appends.

Alternatives considered

The source focuses on one primary design. A second architecture is not compared, so no alternative is invented here.

Failure and degraded modes

The Solution & Trade-offs

• Detection: When a read query executes, the Cassandra coordinator must scan across multiple SSTables on disk and merge the latest values while filtering out tombstoned entries: - The Tombstone Pitfall : If your…
• User or operator impact: When a read query executes, the Cassandra coordinator must scan across multiple SSTables on disk and merge the latest values while filtering out tombstoned entries: - The Tombstone Pitfall : If your…

• When a read query executes, the Cassandra coordinator must scan across multiple SSTables on disk and merge the latest values while filtering out tombstoned entries: - The Tombstone Pitfall : If your workload generates f…