Why is Cassandra so fast for Writes?

There are many design decisions that make Cassandra’s write path extremely efficient. We’ll focus on two. These two carry most of the weight.

• First is Cassandra’s reliance on sequential I/O, which works in perfect harmony with the hardware.

• The second design choice is immutable, append-only writes. By focusing on write performance, Cassandra trades off some read capabilities.

Let’s break this down 👇

Step 1: The write request hits the coordinator node, which routes it to the right replicas.

Step 2: Each replica appends the write to a commit log (for durability). This is a sequential disk write so there is no random access or disk seek which ordinarily slows down databases.

Step 3: The data is written to an in-memory structure called a memtable. Again, no disk I/O here it’s all in RAM.

Step 4: When the memtable fills up, Cassandra flushes it sequentially to disk as an immutable SSTable. Because this structure is immutable, there’s no locking to block and no overwrites, just a new file written in one pass.

Step 5: Later, background compaction merges old SSTables to reclaim space and maintain read efficiency. We can handle all the slow stuff asynchronously, keeping our critical path super fast.

Because Cassandra never updates data in place and relies on fast, sequential writes, it avoids the latency of traditional B-trees and random I/O.