Websites Should Be Printable
Concept of the day · distributed systems
Raft
Consensus you can actually hold in your head: one leader, an append-only log, a majority.
The mechanism. Raft decomposes consensus into three problems. Leader election: nodes are followers until one times out, becomes a candidate, and wins a majority vote for a numbered term. Log replication: all writes go to the leader, which appends them and replicates to followers; an entry commits once a majority have it. Safety: a candidate can only win if its log is at least as up to date as the majority's, which guarantees a new leader never discards committed entries.
Why it exists. Paxos is correct and famously hard to implement correctly. Raft was explicitly designed for understandability — strong leadership, no holes in the log, and terms as a logical clock — and it won: etcd, Consul, TiKV, CockroachDB, RabbitMQ quorum queues, Kafka's KRaft and Redpanda all run Raft or a close variant.
What it costs you. Every write is a majority round trip, so write latency is bounded below by your slowest-of-majority network hop — which is why a three-region Raft group has a floor of tens of milliseconds per write. Throughput is bounded by the leader. A majority must be alive: 3 nodes tolerate 1 failure, 5 tolerate 2. An even number of nodes buys you nothing.
The parts that bite in production. Reading from the leader is not automatically linearizable — a deposed leader may not know it yet, so you need a lease or a read index. Membership changes are a protocol step, not a config edit. And a slow follower can silently become a liability long before it is "down".
Takeaway. Raft gives you a replicated log. Everything else — a KV store, a lock service, a state machine — is what you build on top of it.