Review: Designing Data-Intensive Applications
A critical review of Kleppmann's modern classic — what it gets right, what it misses, and who should read it.

Designing Data-Intensive Applications
Martin Kleppmann • O'Reilly Media • 2017
AI Summary
Generated in 2.3s
A critical review of Kleppmann's modern classic — what it gets right, what it misses, and who should read it.
Key Points
- Best-in-class treatment of replication and consensus.
- Excellent on tradeoffs; never tells you what to do.
- Showing its age on cloud-native and modern stream processing.
- Still the most-recommended book for backend engineers in 2026.
The case for the book
Most engineering books either go deep on one topic or skim many. DDIA threads an unusual needle: it covers an enormous surface area without sacrificing depth. The chapters on replication and consensus are worth the cover price alone. Kleppmann explains Raft, Paxos, and two-phase commit with a clarity I have not seen anywhere else.
Where it shows its age
Published in 2017, the book predates the explosion of cloud-native data infrastructure. There is no meaningful coverage of CRDTs, no serious treatment of lakehouse architectures, and the stream-processing chapter feels quaint next to modern systems like Materialize or RisingWave. None of this is the author’s fault, but a reader should pair the book with more recent material for the last mile.
Who should read it
Any engineer who designs or operates systems that touch more than one machine. That is most of us. Even if you have been in the industry for a decade, the book will sharpen vocabulary you have been using sloppily — eventual consistency, linearizability, isolation levels — and that sharpening is worth the time.
“If I could assign one book to every new database engineer, it would be this one.”

Daniel Abadi
Database Professor, UMD
Advertisement
728 × 90

priya-patel
Staff Engineer
Backend and data infra. Reviews books she wishes she read earlier.
32
Reviews
3.1k
Followers
Comments3


This is exactly what I needed. The breakdown of architectural tradeoffs was particularly illuminating — especially the point about eventual consistency vs. strong consistency being a product decision, not just a technical one.

Agreed. Would love a follow-up that goes deeper on the consensus algorithms.

Curious how this approach holds up at 10x the scale. Have you tested with sharded clusters?