Apache Cassandra — Part 2: Internals & The Write Path

maang.io System Design Series

What is this?

Back to our co-op of corner shops. In Part 1 we saw how the circle decides which shop owns an item. Now zoom into one shop and watch how a good shopkeeper actually handles a delivery. The clever ones don't refile every new item onto the correct dusty shelf the moment it arrives — that's slow. Instead they scribble the delivery in a receiving log (so nothing is ever lost), toss the items into a sorting tray on the counter for instant access, and only later, when the tray is full, do they carry a neatly-sorted batch to the shelves in one efficient trip. Refiling never blocks receiving.

That's exactly how a Cassandra node stores data, and it's why Cassandra writes are astonishingly fast. The trick has a name — the LSM-tree (Log-Structured Merge-tree) — and it's the single most important internal idea in this chapter.

The one-line idea: Cassandra never overwrites data in place. Every write is an append — to a durable log and to a sorted in-memory buffer — and the real filing happens later, in the background, by merging sorted files. Sequential appends are cheap; random in-place updates are expensive; Cassandra simply refuses to do the expensive thing on the hot path.

Let's follow a single write from the moment it lands, then unpack the machinery.