How does Cassandra handle writes with the commit log and memtable?
Learn how Cassandra handles writes using the commit log for durability and the memtable in memory for speed, then flushes to immutable SSTables.
Expected Interview Answer
When Cassandra receives a write, it appends the mutation to the on-disk commit log for durability and simultaneously updates an in-memory structure called the memtable, then acknowledges the client — no random disk seeks are needed.
The commit log is an append-only file that guarantees the write survives a crash before the data is flushed to disk. The memtable is a sorted, per-table in-memory buffer that accumulates writes. When a memtable fills up (by size or time), it is flushed to an immutable SSTable on disk and the corresponding commit-log segments are recycled. This sequential-append design is why Cassandra writes are extremely fast and never overwrite existing data in place.
- Very fast, sequential (no random-seek) writes
- Durability via the commit log even before flush
- Writes are never blocked by reads
- In-memory memtable keeps recent data sorted and hot
- Crash recovery replays the commit log to rebuild memtables
AI Mentor Explanation
Picture the official scorer at a match. The instant a run is scored they scribble it into a rough running notebook (the commit log) so nothing is ever lost, and also update a neat tally board in their head (the memtable). Only at the innings break do they transfer the totals to the permanent, unchangeable printed scorecard. Cassandra writes the same way: jot down for safety, keep a fast mental tally, and flush to durable storage in batches.
Step-by-Step Explanation
Step 1
Client sends a write
A coordinator node receives the mutation and routes it to the replicas that own the partition.
Step 2
Append to commit log
Each replica appends the mutation to its on-disk, append-only commit log for durability.
Step 3
Update the memtable
The same mutation updates the in-memory, sorted memtable for the target table.
Step 4
Acknowledge the client
Once commit log and memtable are updated per the consistency level, the write is acknowledged — no SSTable I/O required.
Step 5
Flush to SSTable
When the memtable hits its threshold, it is flushed to an immutable SSTable and the covered commit-log segments are recycled.
What Interviewer Expects
- Knowing writes hit commit log AND memtable together
- Understanding the commit log provides durability
- Why sequential appends make writes fast
- That memtables flush to immutable SSTables
- Role of the commit log in crash recovery
Common Mistakes
- Saying Cassandra updates data in place on disk
- Confusing the memtable with a read cache
- Forgetting the commit log's durability role
- Thinking each write immediately creates an SSTable
- Believing writes require reading existing data first
Best Answer (HR Friendly)
“When you save data in Cassandra, it first jots the change into a safety log on disk so nothing is lost, and also keeps it in fast memory so the save feels instant. Later, in batches, it writes that memory to permanent files. This is why Cassandra can absorb huge volumes of writes very quickly.”
Code Example
-- Every INSERT/UPDATE is appended to the commit log
-- and applied to the in-memory memtable, then acknowledged.
INSERT INTO users (user_id, name, city)
VALUES (123e4567-e89b-12d3-a456-426614174000, 'Asha', 'Pune');
-- Tuning knobs (cassandra.yaml):
-- commitlog_sync: periodic | batch
-- memtable_flush_writers, memtable_heap_space_in_mb
-- Force a flush of memtables to SSTables:
-- nodetool flush usersFollow-up Questions
- What happens to the commit log after a memtable is flushed?
- What is the difference between periodic and batch commit-log sync?
- How does Cassandra recover data after a crash?
- Why are Cassandra writes considered append-only?
- How does the consistency level affect write acknowledgement?
MCQ Practice
1. Which two structures does a Cassandra write update before being acknowledged?
A write is appended to the commit log for durability and applied to the in-memory memtable before it is acknowledged.
2. Why are Cassandra writes fast?
Appending to the commit log and updating an in-memory memtable avoids random disk seeks, making writes very fast.
3. What triggers a memtable to be written to disk?
A memtable is flushed to an immutable SSTable when it crosses a configured size or time threshold, not on every write.
Flash Cards
What is the commit log? — An append-only on-disk file that durably records every write before it is flushed, used for crash recovery.
What is a memtable? — A sorted, in-memory per-table buffer that accumulates recent writes before being flushed to an SSTable.
When does a memtable flush? — When it reaches a configured size or time threshold, producing a new immutable SSTable.
Why are Cassandra writes fast? — They are sequential appends to the commit log plus in-memory updates — no random disk seeks or read-before-write.