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.
Cassandra is fast at writes and does more work on reads. Both follow from one decision: never modify a file that has been written.
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 has no reads in it. A replica receiving a write does two things:
2
1. append to the commit log sequential disk write, for durability
2. update the memtable in-memory, sorted structure
-> acknowledge3
That is all. No seek to find the existing row, no check whether it exists, no update in place. Appending to
a log and writing to memory are both fast and both stay fast as data grows.
4
When the memtable fills, it is flushed to disk in one sequential pass as an immutable SSTable, and the
commit log segments it covered can be discarded. A crash before the flush is fine — the commit log is
replayed on restart.
5
This is why Cassandra's write throughput is so high, and why an update costs the same as an insert: neither
one looks at what was there before.
6
The read path pays the bill. One row's columns may be spread over the memtable and several SSTables,
because each write went wherever was current at the time. A read must find every fragment and reconcile.
7
1. memtable newest data lives here
2. bloom filter per SSTable: "definitely not here" or "maybe"
3. key cache if seen before, jump straight to the offset
4. partition index otherwise, find the offset on disk
5. read, then merge newest timestamp per column wins8
The bloom filter is what makes this affordable. Without it, a read with 30 SSTables means 30 disk
lookups. The bloom filter is a small in-memory structure that answers "is this partition in this file?"
with either a certain no or a probable yes.
9
A certain no skips the file entirely, with no disk access. A false positive costs one wasted lookup, and
the rate is tunable — lower false positives, more memory.
10
Reconciliation is per column, by timestamp. Not per row. If one SSTable holds the email written at
10:00 and another holds the phone written at 11:00, the result carries both. Last write wins, applied
column by column.
11
This is why clock skew between clients genuinely matters in Cassandra: the timestamp decides the winner,
and a machine with a fast clock can make an older write beat a newer one.
12
What the shape tells you. More SSTables per read means slower reads, which is why compaction strategy
matters and why LCS suits read-heavy tables. Deleted rows still cost read work, because a tombstone must
be read to know the row is gone. And a read is only ever as fast as the slowest replica it waited for,
which is why consistency level is a latency decision as much as a correctness one.
13
What the interviewer is probing.1. "Walk through a write." Probing: the sequence. Stalls: "It writes to disk." Moves up:
commit log for durability, then the memtable in memory, which is flushed to an immutable SSTable
when full.
14
2. "Why are writes so fast?" Probing: the reason. Stalls: "Good hardware." Moves up: they
are append-only with no read beforehand — no read-modify-write and no seek.
15
3. "Walk through a read." Probing: the sequence. Stalls: "It reads the file." Moves up:
memtable, then row cache, then bloom filters to skip SSTables, then the key cache and partition
index, merging versions by timestamp.
16
4. "What is a bloom filter for?" Probing: the optimisation. Stalls: "Caching." Moves up:
telling the engine an SSTable definitely does not contain a key, so most files are skipped without
reading them.