Goal
The path to "Designing Data-Intensive Applications"
Here is the reading path leading up to this book, derived from its dependencies and ordered from the fundamentals.
The path so far (8 books)
Why read this first: Once quality at the function and class level is second nature, the next step is to design the direction of dependencies and boundaries across the whole system. Clean Architecture provides the principle of pushing details outward and keeping business rules at the core.
Why read this first: After gaining an intuition for the ideal shape from Clean Architecture, you formalize architectural characteristics and trade-offs into a shared vocabulary. This book elevates design judgment from personal instinct to a discipline you can reason about.
Why read this first: Only after understanding single-node storage-engine internals do discussions of consistency, replication, and partitioning across multiple nodes become grounded. Kleppmann's 'Designing Data-Intensive Applications' is the capstone that systematizes the principles of distributed data systems, placing internals knowledge as a required prerequisite.
Why read this first: After learning structural 'patterns' of distributed systems from Burns's book, advance to the hard part beyond them—data consistency and fault tolerance. Kleppmann's 'Designing Data-Intensive Applications' digs theoretically into replication, distributed transactions, and consensus, providing the data-layer principles that underpin distributed patterns.
Why read this first: Once you have a vocabulary of architectural characteristics and trade-offs, you apply that judgment to the concrete case of distributed systems. Microservices demand a design that deliberately breaks coupling in exchange for independent deployment and autonomy.
Why read this first: Once you have the idea of guiding evolution with fitness functions, you advance to concrete analysis of the hard parts of distributed architecture—granularity, data ownership, and communication trade-offs—from the same authors.
Why read this first: Once you split services, the next hard problem becomes the distribution, consistency, and reliability of data. DDIA systematically provides the foundational theory and trade-offs of distributed data systems—replication, partitioning, and transactions.
Why read this first: When the hard parts of distributed architecture force decisions about decomposing data, you descend to the underlying theory of distributed data. The principles of consistency, replication, and storage engines become the grounds for your design decisions.