Introduction: Why Raft?
In a world of distributed systems, achieving consensus among multiple nodes is one of the most fundamental — and challenging — problems. When you have a cluster of servers that need to agree on a shared state, you need an algorithm that works correctly even when some servers crash or messages get lost.
Raft was designed by Diego Ongaro and John Ousterhout to be an understandable consensus algorithm. While Paxos had been the gold standard, its notorious difficulty in understanding and implementing led to Raft's creation as a more approachable alternative.
Why Consensus Matters
Consensus is the backbone of any reliable distributed system. Think about databases that replicate data across multiple servers, or configuration services like etcd and ZooKeeper that need every node to agree on the current state. Without consensus:
- Data could diverge across replicas, leading to inconsistencies
- Split-brain scenarios could cause conflicting decisions
- System failures could lead to permanent data loss
Raft Overview
Raft decomposes consensus into three relatively independent subproblems:
- Leader Election: A new leader must be chosen when an existing leader fails. Raft uses randomized election timeouts to ensure elections resolve quickly.
- Log Replication: The leader accepts log entries from clients and replicates them across the cluster, forcing other servers' logs to agree with its own.
- Safety: If any server has applied a particular log entry to its state machine, no other server may apply a different command for the same log index.
Leader Election in Detail
Raft servers are always in one of three states: follower, candidate, or leader. In normal operation, there is exactly one leader and all other servers are followers.
When a follower receives no communication from a leader within its election timeout, it transitions to candidate state, increments its current term, votes for itself, and sends RequestVote RPCs to all other servers. A candidate wins the election if it receives votes from a majority of servers.
The randomized election timeout (typically 150–300ms) is the key mechanism that prevents split votes. Since each server picks a different random timeout, usually only a single server times out first and wins the election before others even start.
Conclusion
Raft achieves the same safety and liveness guarantees as Paxos but does so in a way that's much easier to understand and implement. Its decomposition into leader election, log replication, and safety makes each piece tractable on its own. This is why Raft has become the consensus algorithm of choice for systems like etcd, CockroachDB, TiKV, and many others.