Back to index
OtherAround 590 pages across 12 chapters, two to three months if you read it properly·Around $60 in print, or included with an O'Reilly subscription

Designing Data-Intensive Applications (Martin Kleppmann)

4.8

Not an AI book, and one of the most valuable things an AI engineer can read. Everything downstream of a model runs on the machinery this book explains, and almost nobody in machine learning has been taught any of it.

What We Liked

  • Explains the mechanism behind every distributed system you will ever use, not the marketing description
  • The consistency and consensus chapters are the clearest treatment of a genuinely hard topic anywhere
  • Vendor neutral throughout, so nothing in it expires when a product does
  • Every chapter is backed by references to the original papers, which makes it a launchpad as well as a book
  • Kleppmann is honest about tradeoffs rather than selling an architecture

What Could Be Better

  • Nothing about machine learning, so the relevance is indirect and you have to make the connection yourself
  • The first edition is from 2017 and some of the ecosystem examples have aged noticeably
  • Dense enough that skimming it produces no benefit at all
  • Assumes you have felt the problems it describes, so it lands poorly on someone with no production experience
  • The second edition has been in early release long enough to make the buying decision awkward

Detailed review

I have put a book with no machine learning in it into a catalogue of AI courses, and I want to justify that properly rather than wave at it. The pattern I keep seeing is this. Someone learns to train models, gets good at it, and then joins a team where the model is about four percent of the system. The other ninety six percent is data arriving from places, being stored somewhere, being replicated for reasons nobody documented, being served under a latency budget, and going subtly wrong in ways that look like a modelling problem and are not.

Machine learning education prepares people for the four percent. This book is the best single preparation for the rest, and the reason it works is that it refuses to describe systems from the outside. Kleppmann's method throughout is to take something you use and open it. You know a database has indexes.

This book shows you what a B tree is doing on disk, what an LSM tree does differently, and why that difference determines whether your write heavy workload falls over. You know replication exists. This book walks through single leader, multi leader and leaderless replication, what each one buys you, and precisely which failure modes each one introduces. You have heard of eventual consistency, probably in a sentence where it sounded like a minor caveat.

After chapter five you will understand it is a description of a family of quite specific and quite alarming behaviours, and you will start asking better questions about the systems you already depend on. The chapters on consistency and consensus are the heart of it and they are the best thing I have read on the subject. Linearizability, causality, ordering guarantees and the actual content of the CAP theorem as opposed to the slogan version are laid out with real care. This is material that is usually either hand waved into meaninglessness or presented as formal proofs that teach a practitioner nothing.

Kleppmann finds the level in between, where you come away able to reason about a real system rather than recite a definition. I have watched engineers with years of experience have several uncomfortable realisations in that section, myself included. The chapter on the trouble with distributed systems deserves a specific mention because it is doing something unusual. It is an honest accounting of everything that can go wrong when computers talk over a network, and it is written to break the assumption that a remote call is a slow local call.

Unreliable clocks, partial failures, processes that pause at the worst moment, the impossibility of distinguishing a slow node from a dead one. This is the chapter that turns careless engineers into careful ones. It should be required reading before anyone is allowed to design a retry policy. The final section on batch and stream processing is where the AI relevance becomes direct rather than inferred.

Feature pipelines, training data assembly, online inference and the whole question of how you keep what a model sees in training consistent with what it sees in production are stream processing problems wearing a different hat. Training and serving skew, which costs teams enormous amounts of time, is fundamentally a data pipeline consistency problem. Reading this material will make you better at it than any MLOps course I have reviewed here, because it gives you the underlying model rather than a specific tool's answer. Now the honest limitations.

The book is from 2017 and the specific technologies referenced have moved. Some products named have changed substantially, some have faded, and the cloud managed service landscape looks quite different now. This matters less than you might expect, because the book is about principles and the principles have not changed, but you will occasionally read an example that dates itself. The second edition has been in early release for a long stretch, which puts buyers in an annoying position of choosing between a proven book that is aging and an incomplete one that is current.

My advice is to read the first edition now rather than wait, because the core is stable and delay costs you more than the staleness does. It is also genuinely difficult, and not in a way you can shortcut. Skimming produces nothing. This is a book you read with attention, ideally alongside a system you are responsible for, so that each chapter connects to something you have actually experienced.

Someone reading it before they have run anything in production will find it abstract and will retain very little. The value comes from recognition, from the moment where you realise the confusing incident from last quarter has a name and a well understood cause. There is a fair criticism that the relevance to AI is indirect, and I accept it. Nothing here will help you choose a learning rate or debug a training run.

If you are early in your machine learning education, other things in this catalogue matter more. My 4.8 is close to the top of what I give anything, and it is because this book has a quality almost nothing else has, which is that it does not go out of date and it does not have a real competitor. It is the book that separates people who use distributed systems from people who understand them, and once your model has to run for someone other than you, that distinction becomes your whole job.

[ final ]

The verdict.

Read it in your second or third year of working with data. It will change how you think about every system you touch, including the ones with a model in them.