Introduction

There is a particular kind of suffering reserved for engineers who must make multiple computers agree on something. It’s not the clean suffering of a hard mathematical proof or the dramatic suffering of a production outage at 3 AM (though consensus algorithms cause plenty of both). It’s the slow, grinding suffering of reading a paper that says “the protocol is straightforward” and then spending six months discovering all the ways it isn’t.

This book is about that suffering.

What This Book Covers

We’re going to walk through the major consensus algorithms — Paxos, Raft, PBFT, and their many cousins, variants, and competitors — with a level of honesty that most textbooks avoid. Academic papers have an incentive to make their protocols sound elegant. Vendor documentation has an incentive to make their implementations sound easy. We have neither incentive.

Specifically, we’ll cover:

• Why consensus is hard — not just the impossibility theorems, but the practical reasons that make every implementation a minefield
• The classic protocols — Paxos, Multi-Paxos, Viewstamped Replication, Raft, and Zab, compared on what matters: understandability, performance, and how much you’ll hate debugging them
• Byzantine fault tolerance — PBFT, HotStuff, Tendermint, and the question of whether BFT is worth the overhead outside of blockchains
• Modern variants — EPaxos, Flexible Paxos, Kafka’s ISR, CRDTs, and virtual consensus approaches that try to sidestep the problem entirely
• The honest comparison — tradeoff matrices, decision frameworks, and a frank discussion of why so many teams end up just using whatever Kafka does

Who This Book Is For

This book assumes you know what a distributed system is and have at least a passing familiarity with concepts like replication, partitions, and the general unfairness of network communication. You don’t need to have implemented a consensus algorithm before — but if you have, you’ll appreciate the commiseration.

The ideal reader is someone who:

• Is evaluating consensus algorithms for a real system and wants to understand the tradeoffs without reading twenty papers
• Has read the Raft paper and wonders why it was supposedly the “understandable” one
• Needs to explain to their manager why “just use Paxos” is not a complete engineering plan
• Wants to understand why their ZooKeeper cluster keeps doing weird things
• Is tired of blog posts that explain consensus with analogies about pizza delivery

How to Read This Book

The book is structured in five parts that build on each other, but you don’t have to read linearly.

If you’re new to consensus, start from Part I. The foundations matter more than you think, and skipping the impossibility results will leave you confused about why every protocol has the limitations it does.

If you’re comparing specific protocols, jump to the relevant chapters in Parts II through IV, then read Part V for the comparison framework. Each protocol chapter is designed to be relatively self-contained.

If you’re making a decision right now and don’t have time for theory, go straight to Chapter 20: “When to Use What (and When to Give Up).” It’s the chapter I wish someone had written for me years ago.

If you’re here for the Byzantine stuff, Part III stands on its own, though you’ll want to read Chapter 4 (The Byzantine Generals Problem) first.

A Note on Pseudocode

Throughout this book, we use pseudocode to describe protocol behavior. The pseudocode is designed to be readable by anyone with programming experience — it’s not tied to any particular language. Where the pseudocode necessarily simplifies the actual protocol, we say so explicitly. Where the papers simplify the actual protocol and don’t say so, we also say so explicitly.

A Note on Honesty

Every chapter title in this book contains editorial commentary. “Lamport’s Beautiful Nightmare.” “The One Nobody Reads.” “When You Can’t Trust Anyone.” These aren’t clickbait — they’re honest descriptions of what it’s like to work with these protocols. The academic community has produced brilliant work on consensus, and we respect that work deeply. But respecting it doesn’t mean pretending it’s easy. The gap between a consensus algorithm on a whiteboard and a consensus algorithm in production is where careers go to age prematurely.

Let’s begin.