What to Read After Designing Data-Intensive Applications

Designing Data-Intensive Applications is the book almost everyone reads, and it is the book almost everyone stops at. That is a reasonable place to stop, because it is genuinely good and because it is not obvious what comes next. The follow-up lists you find are usually just twenty book titles in no particular order.

The useful version of this question is not "what is the next best book". It is "what am I trying to do next", because the answer branches sharply. This article sorts the options by goal.

One note before the list. There is now a second edition, co-authored by Martin Kleppmann with Chris Riccomini. It is a substantial revision rather than a refresh, with reworked coverage of newer storage and streaming systems. If you read the first edition several years ago and are looking for a next step, rereading the parts of the second edition that changed is a legitimate answer to this question.

What DDIA gives you, and what it does not

Being precise about the gap makes the next choice easier.

What it gives you: a mental model of storage engines, replication, partitioning, transactions, consistency models, consensus, and batch and stream processing. It explains why systems are built the way they are, and it is unusually honest about tradeoffs. When you finish it, you understand the components.

What it does not give you:

• Operational reality. It describes what fails and why, but not what running these systems is like, how to instrument them, or how to design for the failure rather than around it.
• Interview technique. It is a foundations book. It does not teach you to run a 45-minute design conversation, scope an open question, or estimate.
• Architecture at the service level. It is largely a data-systems book. Service decomposition, API boundaries, and organizational tradeoffs are outside its scope.
• Depth on any one system. It surveys. If you want to know how Kafka or Postgres actually works internally, you need something narrower.

Pick the branch that matches the gap you care about.

Branch 1. Your goal is the system design interview

This is the most common reason people ask this question, and it is the branch where more books are the wrong answer.

The interview does not test whether you know what a quorum is. It tests whether you can take a vague question, bound it, estimate it, choose components, defend the choices, and do all of that in 45 minutes while talking. DDIA taught you the vocabulary. The gap is the performance.

What actually closes it:

• Worked case studies, start to finish. Not "here is how a cache works" but "here is the whole design for a system, in order, with the decisions called out". You need enough of these that a new question feels like a variation rather than a novelty.
• A repeatable method. Requirements, then scale estimates, then a high-level design, then the deep dives the interviewer steers you into.
• Practice out loud. The single most underweighted item on every list.

Grokking the System Design Interview is built around the case-study format for exactly this reason. If the components from DDIA feel shaky rather than the method, Grokking System Design Fundamentals covers the building blocks first. For senior and staff-level design questions that go past the standard case studies, Advanced System Design Interview, Volume II is the next step up.

If you want to keep reading books here, the honest answer is that most system design interview books are worse than DDIA at teaching concepts and no better at teaching the interview. Practice beats another book on this branch.

Branch 2. Your goal is distributed systems depth

If DDIA left you wanting the primary sources, this is the branch. Papers are the correct next medium, not books, because DDIA is largely a synthesis of them and reading them directly is where the detail lives.

Start with these, roughly in this order:

• Amazon Dynamo. Leaderless replication, quorums, vector clocks, and the case for availability over consistency. Read alongside the vector clocks section in DDIA.
• Google Bigtable and MapReduce. The two papers that shaped a decade of infrastructure.
• Google Spanner. Externally consistent distributed transactions and the TrueTime idea. This is the counterargument to Dynamo.
• Raft. Consensus explained in a way you can actually follow, which was the explicit goal of the paper.
• Kafka. The log as a primitive, which reframes stream processing.
• The Google File System and Chubby, for storage and coordination respectively.
• The FLP impossibility result, if you want the theory floor under all of it.

We keep two curated lists for this: System Design Research Papers for a short prioritized set, and System Design White Papers for a wider 40-paper library organized by theme.

For a book on this branch rather than papers, Database Internals by Alex Petrov is the closest thing to a sequel. It goes deeper into storage engine internals and distributed algorithms than DDIA does, and it is written for the same reader.

Branch 3. Your goal is streaming and data systems

DDIA's last chapters open this door and then stop.

• Streaming Systems by Tyler Akidau, Slava Chernyak, and Reuven Lax. The best treatment of event time, watermarks, windowing, and the relationship between batch and streaming. This is the natural continuation of DDIA's final chapters.
• Kafka: The Definitive Guide. Practical rather than conceptual, and useful if you will actually operate Kafka.
• The Data Warehouse Toolkit by Ralph Kimball, if your work drifts toward analytics rather than services. Older, still the reference for dimensional modeling.

Branch 4. Your goal is running systems in production

DDIA is a design book. This branch is about what happens after the design ships, and it is the branch that most improves your system design answers, because production experience is what interviewers are probing for when they ask "what breaks".

• Release It! by Michael Nygard. Stability patterns and antipatterns: circuit breakers, bulkheads, timeouts, and the failure cascades they prevent. If you read one book from this list, read this one. It maps directly onto the failure questions in senior interviews.
• Site Reliability Engineering by Google. Error budgets, service level objectives, and the operational model. Free to read online.
• The Site Reliability Workbook. The practical companion, with worked examples that the first book leaves abstract.

We covered the interview-facing version of this material in 10 Must-Know System Design Failure Modes.

Branch 5. Your goal is architecture breadth

If your next step is designing systems at the service and organization level rather than the data level:

• Fundamentals of Software Architecture by Mark Richards and Neal Ford. A structured survey of architecture styles and the characteristics that drive the choice between them.
• Software Architecture: The Hard Parts, by the same authors with others. Specifically about decomposition decisions, distributed data ownership, and the tradeoffs that have no clean answer. It is the better of the two if you already have experience.
• Building Microservices by Sam Newman. Service boundaries, integration, and the organizational consequences. Read it skeptically, which is how it is written.
• Designing Distributed Systems by Brendan Burns. Short, pattern-oriented, container-centric. A fast read.

Pick one, by goal

The mistake to avoid

The common failure after DDIA is to read four more books of the same kind and mistake accumulated reading for capability. DDIA is unusual in how much it gives you per page, and the next four books will not match that rate, because the easy consolidation has already been done.

At some point the return comes from building something, operating something, or being questioned on something, rather than from reading. If your goal is interviews, that point is right now. If your goal is depth, one more layer of reading is justified, and then the same rule applies.

Frequently asked questions

Is DDIA enough for a system design interview?

It is enough for the concepts and not enough for the interview. Candidates who have read it and nothing else typically know the components well and still struggle with scoping, estimation, and driving the conversation. Those are separate skills. We compared the two directly in DDIA vs Grokking the System Design Interview.

Should I read the second edition if I read the first?

Read the chapters that changed rather than the whole book. The framework is the same; the coverage of newer systems and the reorganized material are where the new value is.

What is the closest thing to a DDIA sequel?

Database Internals by Alex Petrov, if you want more of the same depth on storage and distributed algorithms. Streaming Systems, if the last chapters were the interesting part.

Do I need to read papers, or are summaries enough?

Summaries are fine for interview purposes. Read the originals if you want to reason about design decisions rather than recall them. The Dynamo paper in particular rewards the full read, because the reasoning is more interesting than the result.

How long should this take?

One book per branch, chosen deliberately, is more useful than five books read in order. Pick the branch that matches your next six months.

Related reading

• DDIA vs Grokking the System Design Interview
• System Design Research Papers
• System Design Interview Questions and Case Studies