Apache Cassandra

Read Path & Write Path Internals

Understand the internal steps Cassandra takes to serve a read or write request, including memtables, SSTables, and the commit log.

Understanding Cassandra's write path and read path is essential for reasoning about performance, durability, and consistency behavior at a deeper level than just CQL syntax.

Writing is like quickly jotting notes into a running notebook (memtable) while also keeping a safety carbon-copy (commit log), only bothering to file things into neat folders (SSTables) later. Reading is like checking your current notebook page first, then using a quick 'is it even in this folder' checklist (bloom filter) before digging through your filed folders, and combining whatever pages you find, keeping only the most recently dated version of each fact.

Key Concepts

1
The write path begins when the coordinator sends a mutation to the replica nodes responsible for the partition. Each replica first appends the write to the commit log (an append-only, sequential-write durability log on disk) and then writes the same mutation into an in-memory structure called the memtable. Once the memtable reaches a size threshold, it's flushed to disk as an immutable SSTable, and the corresponding commit log segments can be discarded.
write pathcommit logmemtableSSTable
2
The read path is more involved because data for a single row can be spread across the memtable and multiple SSTables (due to the LSM-tree design). A read first checks the memtable, then consults a bloom filter per SSTable to cheaply rule out SSTables that definitely don't contain the requested partition, then checks the partition key cache and partition summary/index to locate the data efficiently on disk, merging all found fragments together (reconciling by timestamp) to produce the final result.
read pathbloom filterpartition key cachepartition summary/index
3
Both paths are designed around the LSM-tree principle of prioritizing fast sequential writes over read simplicity, trading some read complexity (merging multiple sources) for very high sustained write throughput.