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 3: System Design & Interview Mastery
maang.io System Design Series
What is this?
You now know RocksDB from the Put down to the compaction levels. This chapter is where that knowledge earns the offer. Interviewers almost never ask you to design RocksDB — they ask you to design a stream processor, a stateful service, or a storage layer, and the strong candidates are the ones who say "…and I'd keep that per-key state in an embedded LSM store like RocksDB, because here's why." Recognizing RocksDB as the right component — and defending its costs — is the senior signal.
We'll do two things: see where RocksDB actually shows up in real systems (with diagrams), then run a mock interview — for each question, what they're really asking, a model answer, and the senior line that signals you've operated this for real.
The one-line idea: interviewers use RocksDB to test whether you understand that many "databases" and "stateful systems" are really a distribution/query layer wrapped around an embedded storage engine — and whether you can reason about the LSM amplification trade-offs that engine forces on you.
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