Raft
A consensus algorithm for a replicated log: nodes elect a leader, the leader replicates entries, and a majority commits. Easier to understand than Paxos and the basis of etcd, Consul, and CockroachDB. Provides linearizable writes via majority.
- Metadata, config, locks, coordination (etcd, Consul).
- Any system needing a strongly-consistent replicated log.
- High-throughput data replication (use a DB's own replication).
- When you don't need strong consistency.
Definition
Raft manages a replicated log via a leader. A leader is elected by a majority; clients send writes to the leader, which appends to its log and replicates to followers; an entry is committed once a majority ack. Leader crashes trigger re-election.
Why it exists
Distributed systems need a single agreed-upon log/order for coordination (config, locks, metadata). Raft provides understandable consensus (vs the notoriously opaque Paxos) with the same guarantees.
How it works
Randomized election timeouts pick a leader; the leader sends heartbeats and AppendEntries. A term numbers each leadership. An entry commits when a majority persist it; committed entries are durable. Log matching ensures consistency across nodes.
Scaling limits
Throughput is bounded by the leader (single bottleneck). 3 or 5 nodes typical; large clusters slow elections and writes. Latency is the WAN round trip to a majority. Not for high-throughput data (use it for metadata).
Cost shape
A few nodes for consensus. Blow-ups: WAN latency to a quorum and too-large clusters slowing elections.
Alternatives
- Paxos — Same guarantees, harder to understand/implement.
- Leaderless (Dynamo) — Higher availability, weaker consistency.