Designing Data-Intensive Applications

The one-paragraph verdict

An absolute must-have, and the clearest proof that a technical book ages well when it argues from first principles instead of promoting a product. Kleppmann does the thing most architecture books refuse to: he names the trade-off and then shows you the failure mode on the other side of it. Replication, partitioning, consistency, batch vs. stream — each chapter leaves you with a model you can actually argue from. The common criticism is fair (it’s long, and it’s denser than it looks), but that density is the point. I’ve reread chapters before big decisions more than any other book I own.

Who should read it

Backend and platform engineers, and anyone about to pick a datastore or a consistency model. It is not a beginner’s first programming book — it assumes you’ve felt the pain it describes. If you’ve ever shipped something that lost data under load, this is the book that explains why.

Where it earned its place

The Archives runs a Postgres + Qdrant + object-store split, and almost every call about which store owns what traces back to this book’s framing of derived data and indexes:

• The retrieval design in the RAG pipeline leans directly on its “systems of record vs. derived data” distinction.
• The CNPG Postgres setup and the Qdrant vector store are the system-of-record and derived-index halves of exactly that pattern.

Skip it if…

You want a quick how-to or a single framework’s docs — this is a concepts book, not a recipe. And if you only ever work on a single small CRUD app that will never scale, you can borrow the executive summary: pick boring, well-understood storage and move on.

[Designing Data-Intensive Applications on Goodreads] — Martin Kleppmann , 2017