Why this book
Designing Data-Intensive Applications comes up in nearly every list of books worth reading for software engineers. It is the one book I keep seeing named by people on forums.
My reason is more practical. I have worked on pre-existing systems and built systems at work, and every one of them has taught me something the hard way: a side effect I did not plan for, a failure mode I only understood after it happened. I wanted to replace that scattered, incident-driven learning with something structured, where the ideas come in order and with their trade-offs attached.
The push to finally start came from barista-rs, the tiered fair-share dispatcher I have been building. Shared state, leases, fencing tokens, exactly-once dispatch: each problem I ran into there had a name and a chapter in this book. Every time I went looking for how others had solved a point of failure, I ended up back at DDIA. At some point it made more sense to read the whole thing properly than to keep arriving at it through the back door.
How I am reading it
Not front to back. I am building barista-rs alongside the book, and the system decides the order. When I stumble on a problem there, I find the chapter that covers it and read the whole chapter, not just the section that answers my question. The question I came with is usually the smallest part of what the chapter has to say, and the surrounding context is what keeps the fix from becoming the next problem.
So the chapter notes in this series will not appear in the book's order. They appear in the order barista-rs made me need them.
How these notes work
Each post covers one chapter, or part of a long one, and every post has the same shape.
It opens with the chapter's vocabulary: the terms, jargon and names I met for the first time in that chapter, listed as plain pills with no definitions. It is a map of what is coming, and a checklist to test myself against later.
The body follows the book's own sections and subsections, so a note can be read side by side with the chapter.
Each post then closes with the same five blocks:
- The big idea: the chapter in a few sentences.
- Concepts: the terms and mechanisms worth remembering.
- Trade-offs: what each approach gives up.
- In the wild: where it shows up in real systems, including ones I have worked on.
- Takeaways and open questions: what I am keeping, and what I still cannot answer.
Last comes the vocabulary again, this time with each term defined.