# Designing Data-Intensive Applications (DDIA): What to Read and What to Skip

Arslan Ahmad

April 21st, 2026

DDIA is the standard book on how databases and distributed systems work. Here is what it covers, which parts pay off in a system design interview, what to skip, and what the second edition changed.

_Designing Data-Intensive Applications_, usually shortened to DDIA, is a book by Martin Kleppmann about how databases and distributed systems actually work. It is the most recommended book in system design preparation.

It is also the most abandoned. The book is long, and it rewards patience rather than urgency.

So the useful question is not whether DDIA is good. It is which parts of it repay the time you have.

This article covers what the book is and what the second edition changed. It then sorts the topics into what matters for an interview and what can wait. It ends with when a course is the better use of the same hours.

## What DDIA is

DDIA explains the machinery underneath data systems. Not how to configure one tool, but how the whole category works and where each design gives something up.

It covers storage engines, replication, partitioning, transactions, consistency, consensus, and batch and stream processing. Each topic is treated the same way. Here is the problem, here are the approaches people use, here is what each one costs.

Two things it is not. It is not an interview book, so it contains no worked interview questions and no framework for answering one. It is also not a tutorial, so you will not finish a chapter with something running.

That gap is the whole reason this page exists. DDIA builds the judgment behind a good answer. It does not teach you to produce that answer in 45 minutes.

## What the second edition changed

There are now two editions in circulation, and it is worth knowing which one you are buying.

The second edition is co-authored by Martin Kleppmann and Chris Riccomini, and it runs to 14 chapters. The material was reorganized, so chapter numbers do not line up between the editions.

That matters in one practical way. A lot of the reading advice online points you at chapter numbers.

Follow it with the other edition open and you will be reading the wrong section. Go by topic name instead, which is how the rest of this article is organized.

The reference list for the second edition is published free by the authors at [github.com/ept/ddia2-references](https://github.com/ept/ddia2-references). It is a good way to see the range of material each chapter draws on before you buy.

## Which topics pay off in a system design interview

Interviews reward a small number of ideas from this book, and they reward them heavily. These are the ones worth reading closely.

**Replication.** How data is copied to more than one machine, and what happens when the copies disagree. Single leader, multi leader, and leaderless replication, and the lag that comes with each. Nearly every design question touches this.

**Partitioning.** How a dataset is split across machines, usually called sharding. How keys are assigned to partitions, and what happens when one partition gets far more traffic than the others.

**Transactions and isolation.** What a transaction actually guarantees, and what the weaker isolation levels quietly allow. Read committed, snapshot isolation, and the anomalies each one still permits.

**Consistency models.** What "eventually consistent" means in practice. How it differs from a linearizable system, which is one that behaves as though a single copy of the data existed. This is the vocabulary interviewers listen for when you describe a trade-off.

**Storage engines.** How B-trees and LSM-trees differ, and why one favors reads and the other writes. This is the reason behind half of the database choices you will be asked to defend.

**Stream processing.** Events, logs, and the difference between processing a batch and processing a stream. Useful for any design with a feed, a notification, or an analytics path.

Read those and you can hold a real conversation about trade-offs, which is most of what a design round measures.

## What you can skip for now

Skipping here means leaving until after the interview, not never reading.

**The academic depth on consensus.** Understanding what consensus is for, and that it is expensive, is enough. The proofs and the protocol details are excellent engineering material and rarely change an interview answer.

**Encoding and schema evolution.** It matters enormously in real systems and comes up in interviews mainly as a passing mention of backward compatibility.

**The long research references.** Each chapter ends with a large bibliography. On a first pass they are a way to lose a week.

**Batch processing internals.** The MapReduce lineage is worth knowing about at a high level. The detailed mechanics are the least likely part of the book to appear in a product design round.

## Is DDIA still relevant?

Yes, and for a specific reason. The book is about the constraints of distributed systems, and those constraints have not moved. Network partitions, clock skew, and the cost of coordination behave the same way now as when the first edition was written.

What ages is the tooling around them. That is the part the second edition updates.

If someone tells you DDIA is outdated, they usually mean the product names in the examples. The reasoning is what you are there for, and it holds.

## How to read it without stalling

Most people who abandon DDIA do it the same way. They start at page one and try to absorb everything.

Read for the trade-off, not the detail. In each section, find the sentence that says what this approach gives up.

Write that down. That single sentence is what you will use in an interview.

Take the topics in the order above rather than the order of the book. Replication and partitioning first, because they carry the most weight in a design discussion.

Skip the references on the first pass. Set a pace you can hold, one topic a week, and accept that a second reading is where the depth arrives.

## DDIA or a course?

They answer different questions, so the honest answer depends on your timeline.

|  | DDIA | An interview course |
| --- | --- | --- |
| Teaches | How data systems work | How to answer a design question |
| Format | A book you read | Lessons and worked case studies |
| Time to value | Weeks to months | Days |
| Gives you | Judgment about trade-offs | A repeatable structure, and practice |
| Weakness | No interview framework, no practice | Less depth on database internals |

If your interview is months away, read the book. It will make you better at the job, and the interview follows from that.

If your interview is in a few weeks, a course is the better use of the time, because the failure it prevents is different. Most people who fail a design round do not fail on database theory.

They fail on structure, on requirements they never agreed, and on an answer that never reached a conclusion. [Grokking the System Design Interview](/content/course/grokking-the-system-design-interview?utm_source=blog&utm_medium=blog&utm_campaign=ddia-guide-mid/index.html) is built around that failure, with 15 design questions worked from requirements to a final design.

The two work well together, in a specific order. Use the course to get a structure you can repeat, then use DDIA to deepen the parts you found yourself hand-waving.

## Frequently asked questions

**Is DDIA worth reading?**  
Yes, if you have the time for it. It is the clearest explanation of distributed data systems available, and the understanding lasts far beyond one interview. It is a poor choice as your only preparation for a round that is two weeks away.

**Is DDIA enough for a system design interview?**  
No, on its own. It gives you the reasoning but no framework and no practice. Candidates who read it and skip practice tend to explain mechanisms well and still run out of time without a complete design.

**Which edition should I buy?**  
The second edition, co-authored with Chris Riccomini, if you are buying now. Both are in circulation, so check the author line before you order. If you already own the first edition, it is still worth reading; the fundamentals did not change.

**How long does it take to read?**  
Most people take two to three months at a sustainable pace. Reading only the interview-relevant topics above is a much shorter job, closer to two weeks.

**Is there a free PDF of DDIA?**  
No official free copy exists. The reference lists are published free by the authors, and many of the papers they cite are open access. The book itself is a paid title.

**Do I need DDIA for an entry-level interview?**  
No. Entry-level design rounds stay well above the level of storage engines and consensus. Learn the building blocks and practise a few questions instead.