Designing Data-Intensive Applications

About the book

Martin Kleppmann's book examines the recurring problems that data systems face and the design choices available for solving them. Reliability, scalability and maintainability organize the material. The discussion moves across storage engines, replication, partitioning and distributed coordination, treating each as a set of trade-offs with costs and benefits.

The book is structured around concepts. Different databases and processing tools appear as examples of underlying ideas, which lets a reader compare approaches without tying the reasoning to one vendor or version. Kleppmann writes for practitioners who already write software and want to understand why systems behave as they do under load, failure and change.

The conceptual material on storage, replication and consistency has aged well. Specific tools and their feature sets have moved on, so product references work best as illustrations of principles.

How to read it

Read with a pencil and expect to work. The chapters build arguments from first principles, and the value comes from following the reasoning about trade-offs. Where a section compares options, ask what workload and failure assumptions make each choice sensible.

The examples are deliberately concrete, but they are teaching devices. A reader who wants to apply the material should connect each idea to a system they know and test the claims against their own operational experience. Skimming for answers will miss the qualifications that make the arguments useful.

Who it suits

Software engineers who design or operate data systems will get the most from this book, especially those moving from application code into infrastructure work. Architects who need to justify storage and consistency decisions will find vocabulary and framing for those conversations. Readers with some professional experience and curiosity about how databases and distributed systems work under the surface are the intended audience.

Reading considerations

The book is long and dense, and it assumes comfort with programming and basic systems concepts. Tool references are dated, so check current documentation before making product decisions. The treatment is conceptual, so it will not substitute for operational runbooks or vendor guidance on a specific deployment.