Designing Data Intensive Applications
by Martin Kleppmann, Chris Riccomini
Martin Kleppmann wrote it after years of working on real distributed systems, and it reads like someone explaining why things are the way they are not a spec sheet, not a tutorial for one specific tool. It walks through how databases actually store your data on disk, why replication is harder than it sounds, what happens when your data gets too big for one machine, and why "consistency" means five different things depending on who you ask.
Designing Data-Intensive Applications
Why I recommend it
This is the book that made me stop thinking about databases as black boxes and start understanding what's actually happening underneath. It doesn't teach you a tool — it teaches you *why* the tools were built the way they were, so every system you touch after this makes more sense.
Key ideas
- Reliability, Scalability, Maintainability — the three lenses Kleppmann keeps coming back to when judging whether a design decision is actually good.
- Replication trade-offs — single-leader vs. multi-leader vs. leaderless isn't a technical footnote, it's the difference between "works fine" and "silently loses data" at scale.
- The CAP theorem, properly explained — most people quote it wrong; this book finally makes it click what you're really trading off.
- Batch vs. stream processing — the same data problem, viewed through two very different lenses, and why modern systems often need both.
My takeaway
Once you've read this, you can't unsee the trade-offs baked into every database and message queue you use. It's dense, but it rewires how you evaluate systems — not "which database is best" but "what am I actually optimizing for here."