Designing Data-Intensive Applications

What the book covers

The book, widely known as DDIA, explains how data systems work underneath the APIs you use every day:

• Foundations: reliability, scalability and maintainability; data models and query languages; storage engines (log structured merge trees and B-trees); encoding and schema evolution.
• Distributed data: replication (single leader, multi leader, leaderless), partitioning or sharding, transactions and isolation levels, the trouble with distributed systems (unreliable networks and clocks), and consistency and consensus.
• Derived data: batch processing, stream processing and how to build systems out of logs and derived views.

Which edition to get

The second edition, by Martin Kleppmann and Chris Riccomini, was published by O'Reilly in March 2026 and runs to about 650 pages. The authors kept the core structure and ideas but refreshed the details throughout. A major theme is how cloud services have changed the way data systems are built and used compared with ten years ago. If you are buying today, choose the second edition; the first edition (2017) is still valuable if you already own it.

Why it has the reputation it has

It refuses to hand wave. Where most material says a system is "eventually consistent" and moves on, DDIA explains what anomalies that allows, what it takes to prevent them and what you give up either way. It is also unusually readable for a technical book, with clear diagrams and a steady pace. Reviewers across the industry commonly call it the one book every backend engineer should read.

How long it really takes

This is not a weekend read. A realistic pace for a working engineer is one or two chapters a week, which means two to four months for the whole book. The replication, partitioning, transactions and consistency chapters are the ones that change how you think; slow down there. The batch and stream chapters are excellent but more specialised.

What you need first

• Some experience with at least one relational database and one other data store.
• Comfort reading pseudo code and diagrams. No heavy maths is required.
• Ideally, having seen a production incident or two. The book lands harder when you recognise the failure modes.

How to get the most from it

• Read with a real system in mind (your company's database or your final year project) and ask how each chapter applies to it.
• After each chapter, write a one page summary of the trade offs, not the definitions.
• Follow the references for topics you care about. The bibliography is one of the best reading lists in the field.
• Read it with a colleague or study group and discuss one chapter a week.

Is it good for interviews?

It gives you depth that shows in design discussions, especially around consistency and replication. It is not a fast route to passing a design round, and it does not teach the interview format. It is a better long term investment than that.

Pair it with

• Martin Kleppmann's free Cambridge distributed systems lecture series for the theory behind the consistency chapters.
• Understanding Distributed Systems by Roberto Vitillo for a shorter, gentler first pass.

Best for: backend, data and platform engineers who want solid foundations in how data systems really behave.