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

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. 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.