RocksDB
maang.io System Design Series
RocksDB is an embeddable, high-performance LSM-tree key-value store (a LevelDB fork) that shows up as the storage engine inside other systems — Kafka Streams, Flink state, MyRocks, CockroachDB. Master its write path (memtable → WAL → SSTables), leveled compaction, and the write/read/space-amplification trade-offs, and you understand the engine under half the modern data infrastructure.
This deep dive comes in three parts:
- Foundations & Core Concepts — the LSM model, column families, and where RocksDB is embedded.
- Internals — compaction strategies, bloom filters, block cache, and amplification tuning, with worked numbers.
- Interview — Staff/Principal Q&A: LSM vs B-tree and tuning for a workload.
RocksDB — Part 2: Internals & Implementation
maang.io System Design Series
What is this?
Back to the desk. In Part 1 we watched the fast worker drop forms into an inbox tray, scribble each into a carbon-copy journal, and only later photocopy full trays into shelved binders. That's the shape. Now we open the drawers and see the machinery: exactly what happens on a write, what an SST file actually contains, what a read has to touch to find your key, and how the background re-filing (compaction) is organized — because that organization is where all the interesting trade-offs live.
The one-line idea: RocksDB never updates data in place. A write is an append (to the WAL) plus an in-memory insert (to the memtable); everything else — flushing, merging, reclaiming space, keeping reads fast — is deferred to background compaction, and the shape of that compaction is the single biggest lever you have over write, read, and space cost.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson