Raft Consensus Algorithm

Raft is a consensus protocol that allows a cluster of nodes to agree on a single, replicated log despite node failures and network partitions. It decomposes consensus into leader election, log replication, and safety, making distributed state machines auditable and implementable without relying on Paxos's notoriously opaque proof structure.

Raft operates on a strict leader-based replication model. At any given time, a cluster of N nodes (typically an odd number to avoid split-brain in quorum math) elects exactly one Leader; all writes must be routed through it. The Leader appends entries to its local log, then replicates them to Followers via AppendEntries RPCs. An entry is considered committed only once a majority (quorum) of nodes have persisted it to durable storage. This majority requirement is the core safety mechanism: it guarantees that any committed entry survives the crash of a minority of nodes, and that no two leaders in the same term can both commit conflicting entries at the same index.

Leader election is driven by randomized election timeouts (commonly 150-300ms) to avoid split-vote scenarios. When a Follower doesn’t receive a heartbeat within its timeout, it transitions to Candidate, increments the current term (a monotonically increasing epoch counter), and issues RequestVote RPCs. A node grants its vote only if the candidate’s log is at least as up-to-date as its own, determined by comparing the (lastLogTerm, lastLogIndex) tuple. This log-comparison rule is what prevents a node with a stale log from ever becoming leader and overwriting committed history.

Operationally, several edge cases dominate production incident reports:

Log divergence on leader change: A new leader may have uncommitted entries from a previous leader in follower logs. Raft resolves this not by voting per-entry, but by forcing followers to overwrite conflicting suffixes to match the new leader’s log—never by merging.
The Commit Index visibility gap: A leader can only advance its commitIndex for entries from its own term. Entries replicated from prior terms are only implicitly committed when a subsequent entry in the current term is committed, preventing a subtle bug where an old-term entry could be considered safe prematurely.
Membership changes: Naive reconfiguration (swapping the node set) risks two disjoint majorities forming simultaneously. Production implementations use joint consensus or single-server-change-at-a-time protocols to guarantee overlapping quorums during transition.
Snapshotting: Since the log grows unbounded, implementations periodically compact it into a state machine snapshot, requiring a separate InstallSnapshot RPC path for lagging followers who cannot be caught up via incremental log replication alone.

Architecturally, choosing Raft implies accepting a CP (Consistent, Partition-tolerant) stance under CAP—the cluster sacrifices availability during leader election gaps and network partitions to guarantee linearizable writes. This makes Raft the substrate of choice for systems requiring strongly consistent metadata stores (etcd, Consul, CockroachDB’s Range replication) but a poor fit for high-throughput, latency-sensitive write paths where eventual consistency or CRDT-based approaches would better serve availability requirements.