Author: Martin Kleppmann · Published: 2017 · Genre: Software Engineering, Distributed Systems
The biggest strength of Designing Data-Intensive Applications is that it explains how databases and distributed systems actually work, from storage engines to consensus, in clear prose that never hides the hard trade-offs. Its biggest weakness is that it is a long, dense book about principles rather than a hands-on guide, and the first edition’s batch-processing material leans on the Hadoop era. Any backend or data engineer should read it. It is one of the rare technical books that deserves its reputation.
The core ideas
The book moves from single machines to distributed systems to whole data pipelines.
- Reliability, scalability, maintainability. Kleppmann defines each concretely. His Twitter example shows how to describe load: build each user’s home timeline when they read it, or push every new tweet into followers’ cached timelines when it is written. The right answer depends on the numbers.
- Storage engines. Log-structured storage (SSTables and LSM-trees) is compared with page-oriented B-trees: why one tends to favor write throughput and the other predictable reads. This part also covers column-oriented storage for analytics and how data encodings such as Avro, Thrift and Protocol Buffers handle schema changes.
- Replication and partitioning. Single-leader, multi-leader and leaderless replication each come with their failure modes, including the anomalies replication lag causes, such as not seeing your own write.
- Transactions. What ACID actually means, why weak isolation levels like read committed and snapshot isolation still allow anomalies such as lost updates and write skew, and what true serializability costs.
- Distributed trouble and derived data. Networks drop messages, clocks drift and processes pause. From there the book covers linearizability and consensus, then batch processing, stream processing, change data capture and event sourcing, with the log as the backbone of a data system.
What’s great
- Why, not just what. Instead of comparing products, Kleppmann explains the mechanisms underneath them, so the knowledge survives whichever database is fashionable next year.
- Cutting through marketing. He shows how words like “consistency” and even isolation level names mean different things in different databases, and why the CAP theorem is less useful for design than its fame suggests.
- References. Each chapter ends with a long list of papers, documentation and blog posts, making the book a map of the field’s literature. Fittingly, each chapter also opens with an illustrated map.
- Ethics. The final chapter includes a thoughtful section on privacy, surveillance and the responsibilities of people who build data systems, which most technical books skip.
What’s weak
It is long, at around 600 pages, and dense. Some chapters, particularly on consistency and consensus, need a second reading.
It won’t teach you to run anything. There are no exercises, no configuration advice and no guidance on tuning PostgreSQL or operating Kafka. Readers hoping for a system-design interview guide will find the material relevant but not organized for that purpose.
The first edition is also dated in places. The batch-processing chapter centers on MapReduce and Hadoop, and the book says relatively little about the managed cloud services, data warehouses and object storage that many teams now build on. A second edition, co-written with Chris Riccomini and published in 2026, updates the material and adds coverage of how major cloud services are designed.
Who should read it
Backend, data and infrastructure engineers with a year or two of experience, and senior engineers who want to fill gaps. Read the 2026 second edition if you can. The first edition’s sections on storage, replication, transactions and distributed systems remain excellent.
Rating: 5/5
Image credits — Featured image: cover image via Open Library; cover design © the publisher, shown for review purposes. In-article images: Photo by Taylor Vick on Unsplash.
