Build Raft — consensus you can defend

Imagine three servers that all need to give the same answer. They might be storing your account's current password, the count of likes on a tweet, or which row in a database currently belongs to which transaction. The hard part: any of these servers can crash, restart, miss network packets, or briefly become unreachable. As an operator you can't predict which one — but the cluster as a whole still has to give one consistent answer to every client. That's the problem consensus solves, and Raft is the protocol most modern infrastructure uses to solve it.

You've almost certainly used a Raft cluster without realizing. Kubernetes' object model lives in etcd — a Raft cluster. Consul stores service discovery in one. CockroachDB runs thousands of small Raft groups per node, one per range of keys. TiKV does the same. Every one of these teams reads the same Ongaro & Ousterhout paper and ships a slightly different Raft — and the differences are where the production gotchas live.

If you've used these systems but haven't built one, you probably can't yet answer: what is the difference between term and index (both are integers Raft maintains, and they do very different jobs)? Why is the one-line rule "a leader only commits log entries from its own term" the rule that prevents the worst correctness bug in the protocol — the bug Diego Ongaro called out by name as Figure 8? What's the difference between Pre-Vote and CheckQuorum, and why do production deployments need both? Why are naive reads from the Raft leader actually NOT linearizable (a property that says reads see all writes that have completed before them), and what two production fixes restore the property?

This curriculum walks you from "what is consensus and why do we need it" all the way to "I can defend the production configuration of etcd or CockroachDB." It builds the protocol's actual vocabulary one term at a time — every new word gets a plain-English explanation, then an analogy where it helps, then the precise definition every Raft implementation actually uses. By scene 12 (the design canvas) you should be able to read the etcd source code, recognize what every knob does, and explain why a metadata store ships radically different settings than a queue manager — even though both use the same protocol.

You don't need to know any distributed-systems theory walking in. You DO need to know what a server is, what a client is, what a network partition is, and that machines can crash. That's the entry contract.