Designing Data-Intensive Applications

Kleppmann's premise is that the technology landscape changes constantly but the underlying problems do not, so the useful thing to teach is the reasoning rather than the tools.

The result is a book that names almost every major system while recommending none. It explains what a class of system can and cannot do, and why, so a reader can evaluate the next one without waiting for someone to write about it.

It names the systems and recommends none. What it teaches is how to evaluate the one that does not exist yet.

Devmark’s reading — not a quotation from the book

The opening chapter establishes the three properties everything else is measured against, and is more careful than the familiar words suggest.

Reliability is continuing to work correctly when things go wrong, including human error, which he treats as the dominant cause. Scalability is defined as the ability to cope with growth, with the insistence that it be discussed with specific load parameters. Maintainability is broken into operability, simplicity and evolvability.

A small section with outsized practical value. Kleppmann argues that average response time is nearly useless and that latency should be discussed in percentiles — p50, p95, p99 — because the tail is where the experience actually lives.

He also explains head-of-line blocking and why measuring on the client side rather than the server is necessary to see queueing delay at all. This section alone changes how most teams talk about performance.

The chapter explaining log-structured merge trees against B-trees is the clearest treatment available. It builds an engine from first principles — an append-only log, then an index, then compaction — so the reader understands why the two families make opposite trade-offs.

The result is that a reader can reason about which workloads suit which engine rather than memorising which database uses what.

Kleppmann covers single-leader, multi-leader and leaderless replication, and is unusually good on the consequences that leak into application code.

Read-after-write consistency, monotonic reads and consistent prefix reads are each explained through the user-visible symptom first — a user not seeing their own comment, time appearing to move backwards — which makes abstract consistency guarantees concrete in a way most treatments do not.

The chapter most likely to change a reader's practice. Kleppmann works through the race conditions each isolation level does and does not prevent: dirty reads, dirty writes, read skew, lost updates, write skew and phantoms.

His treatment of write skew is particularly valuable, because it is the anomaly most developers have never heard of and it is not prevented by snapshot isolation — which is what most databases actually give you when they say "repeatable read".

Most databases do not give you the isolation level you think you asked for, and the gap has a name.

Devmark’s reading — not a quotation from the book

The chapter on unreliable networks, clocks and processes is the book's most sobering. Kleppmann shows that partial failure is the defining difficulty: a request that has not returned may have succeeded, failed, or be about to succeed, and there is no way to tell.

His treatment of clocks is essential — that time-of-day clocks can jump backwards, that NTP drift is real, and that using timestamps for ordering across machines is a bug waiting for a busy afternoon.

The theoretical chapter, and the hardest. Linearizability, ordering guarantees, total order broadcast, and the equivalence between consensus and several problems that do not look like consensus.

Kleppmann's handling of the CAP theorem is a notable service: he explains why the popular "pick two of three" formulation is misleading, and what the theorem actually says. That correction alone is worth the chapter.

The final chapters trace the lineage from MapReduce through dataflow engines to stream processing, and make the case that batch and stream are two points on one continuum rather than different disciplines.

The treatment of event sourcing, change data capture and the distinction between event time and processing time is the clearest introduction to stream semantics in general circulation.

It is long, dense, and not a tutorial — there is no code to run and no system to build. Some specific product references have dated, and the second edition has been long in preparation.

But the reasoning has not dated at all, because it is about the physics of distributed state rather than about vendors. It has become the standard reference for exactly that reason: it teaches what remains true after the tools change.