19,866 words, 4 top-level sections, 7 exercises. Three architectures, and the chapter's real work is teaching you what each one gives up. This is a map of how to read it — what to read closely, what to skim, where to stop and run something, and which passages get misread.
tools/verify_quotes.py (14/14 at publish time). Everything else — read-weights, misreads, cross-chapter threads — is my editorial judgment. Words in [grey brackets] inside a quote are also mine, supplying a referent the excerpt leaves dangling; the checker enforces that the text around them is the book's. Trust the quotes; argue with the rest.
This chapter assumes less than the ones around it, which is why it reads easily and misleads badly. Ch. 1 — the reasons to distribute at all (latency, availability, read throughput); the chapter opens by naming them and never re-argues them. Ch. 4 — the write-ahead log, because §"Write-ahead log shipping" is one of the three replication-log formats and assumes you know what a WAL already is. Nothing else is load-bearing. Note the scope line the chapter sets in its second paragraph and quietly relies on throughout: we will assume that your dataset is small enough that each machine can hold a copy of the entire dataset
. Every "just add a replica" argument here dies in Ch. 7.
If the data that you're replicating does not change over time, replication is easy; you just need to copy the data to every node once, and you're done. All the difficulty in replication lies in handling changes to replicated data, and that's what this chapter is about.
Read the three architectures as three answers to where do changes get ordered. Single-leader orders them at one node; multi-leader orders them nowhere and pays in conflicts; leaderless orders them nowhere and pays in quorums and version vectors. Every trade-off in the chapter is downstream of that one question.
| Section | Words | Read | What it's for | Then run |
|---|---|---|---|---|
| Single-Leader Replication — 6,745 · the baseline the other two are deviations from | ||||
| Synchronous Versus Asynchronous Replication | 641 | Close | Short and the highest-value 641 words in the chapter. The semisynchronous compromise is what your database actually does. | — |
| Setting Up New Followers | 883 | Ref | Snapshot + log position + catch up. The "Databases Backed by Object Storage" box is a good 2025 aside, unrelated to the chapter's argument. | — |
| Handling Node Outages | 1,290 | Skim → Close | Skim §"Follower failure"; read §"Leader failure: Failover" closely — the GitHub incident and split brain are the chapter's sharpest war stories. | — |
| Implementation of Replication Logs | 999 | Close | Three log formats, three different operational consequences. The one that decides whether you can upgrade without downtime. | statement-based-replication |
| Problems with Replication Lag | 2,128 | Close | The core of the chapter and the source of every anomaly you'll meet in production. Three named guarantees, three exercises. | read-your-writes, monotonic-reads |
| Solutions for Replication Lag | 338 | Close | Tiny. Its actual advice is "use a database that doesn't have this problem." | — |
| Multi-Leader Replication — 5,370 | ||||
| Geographically Distributed Operation | 1,309 | Close | The four-way comparison (performance, regional outages, network problems, consistency) is the decision table. | — |
| Sync Engines and Local-First Software | 1,138 | Skim | New in 2e and genuinely interesting — Figma, Linear, Automerge — but it's an application of the model, not part of it. Skip if you're here for databases. | — |
| Dealing with Conflicting Writes | 2,649 | Close | The densest subsection in the chapter. LWW, siblings, CRDTs and OT, and the Amazon cart anomaly. | lww-clock-skew, g-counter-crdt |
| Leaderless Replication — 5,425 | ||||
| Writing to the Database When a Node Is Down | 2,164 | Close | Quorums, read repair, hinted handoff — and then the list of cases where w + r > n isn't enough. | quorum-limits |
| Single-Leader Versus Leaderless Replication Performance | 721 | Close | New in 2e, and the best argument in the chapter for leaderless: no failover means gray failures cost you nothing. | — |
| Multi-Region Operation | 233 | Ref | Cassandra/Riak specifics. | — |
| Detecting Concurrent Writes | 2,032 | Close | The payoff. Happens-before, siblings, version vectors — and the definition of "concurrent" that the rest of the book uses. | version-vectors |
| Summary | 2,326 | Ref | The three-guarantee recap (read-after-write, monotonic reads, consistent prefix) is worth re-reading; the rest restates. | — |
1. Asynchronous replication makes "committed" conditional. The single most consequential sentence about the configuration almost everyone runs, buried in the failover subsection:
The most common solution is for the old leader's unreplicated writes to simply be discarded, which means that writes you believed to be committed weren't durable after all.
2. LWW does not mean "last." The chapter defines the term and then immediately says the term is wrong — and this is the claim lww-clock-skew makes physical:
the real meaning of LWW is this: when the same record is concurrently written on different leaders, one of those writes is randomly chosen to be the winner and the other writes are silently discarded, even though they were successfully processed by their respective leaders
"Randomly" is doing real work there. It is not "the newer one wins"; it is "an arbitrary one wins, and you are not told."
3. w + r > n is a probability, not a guarantee. The condition is derived cleanly, illustrated, and then walked back over five bullet points — quorum-limits is the exercise for exactly this gap:
although quorums appear to guarantee that a read returns the latest written value, in practice it is not so simple
The chapter's own summary of what w and r actually buy you: it's wise to not take them as absolute guarantees
.
4. "Concurrent" is defined by knowledge, not by clocks. The definition the rest of the book (Ch. 9, Ch. 10, Ch. 13) is built on, and the one version-vectors implements:
we can simply say that two operations are concurrent if neither happens before the other
The sidebar makes the consequence explicit: two writes made hours apart are concurrent if neither knew about the other. Time doesn't enter into it.
5. Multi-leader forfeits constraints, permanently. Not a limitation of any particular product — the reason single-leader survives:
you can't guarantee that a bank account won't go negative or that a username is unique; it's always possible for different leaders to process writes that are individually fine (paying out some of the money in an account, registering a particular username) but that violate the constraint when taken together with another write on another leader
If your invariant spans writes, you need a single point of ordering. Ch. 13's uniqueness-needs-total-order is this sentence turned into a running system.
"Eventual consistency means a second or two." It means no bound at all. The word is vague on purpose, and the chapter says so:
The term "eventually" is deliberately vague; in general, there is no limit to how far a replica can fall behind.
If you read one thing closely in this chapter, make it §"Problems with Replication Lag." Every "it'll have caught up by then" assumption dies here.
"Synchronous replication means my followers are all up to date." No database does that, because none could survive it:
it is impracticable for all followers to be synchronous; any one node outage would cause the whole system to grind to a halt
What you actually get is semisynchronous — one synchronous follower, the rest async — so "synchronously replicated" means two copies, not all of them.
"Read-your-writes and monotonic reads are the same guarantee." They fail for different people. Read-after-write is about your own writes and says nothing about anyone else's; monotonic reads is about ordering across your own reads:
monotonic reads mean only that if one user makes several reads in sequence, they will not see time go backward
Run read-your-writes and monotonic-reads back to back — same lag, same cluster, two distinct failures, two distinct fixes (route to the leader vs. pin to one replica).
"Statement-based replication is just shipping SQL, so it's fine." It is the one replication format that can silently diverge two replicas that both applied every write:
Any statement that calls a nondeterministic function, such as NOW to get the current date and time or RAND to get a random number, is likely to generate a different value on each replica.
statement-based-replication produces the divergence in two rows.
"CRDTs solve conflict resolution." They automate merging; they cannot invent an answer that doesn't exist:
There are limits to what is possible with conflict resolution. For example, if you want to enforce that a list contains no more than five items, and multiple users concurrently add items to the list so that there are more than five in total, your only option is to drop some of the items.
Which is claim 5 again, from the other side. g-counter-crdt shows what convergence does buy — 80 increments preserved that LWW throws away.
"A version vector is a vector clock." Two different structures with an unhelpfully similar name; the book flags it in a note rather than a section, so it is easy to miss:
when comparing the state of replicas, version vectors are the right data structure to use
Back: Ch. 1 — the availability/latency/throughput case for replicating at all, assumed rather than restated. Ch. 4 — the write-ahead log that "WAL shipping" ships, and the reason that format couples replication to the storage engine version.
Forward: Ch. 7 is the direct sequel — this chapter's stated assumption is that the whole dataset fits on one machine, and sharding removes it. Ch. 8 supplies what §"Solutions for Replication Lag" recommends and doesn't explain (transactions), and its write-skew story is the single-node version of claim 5. Ch. 9 explains why LWW's timestamps can't be trusted — clock skew is assumed here, formalized there. Ch. 10 supplies both things this chapter defers: the consensus that makes leader election safe, and linearizability, the guarantee "read from the leader" is reaching for. Ch. 12 picks up the logical log as change data capture. Ch. 13 returns to conflict detection at scale.