The Raft Consensus Algorithm, Explained

Raft is a consensus algorithm that lets a cluster of servers agree on a single, consistent sequence of operations even when individual nodes crash or network messages get delayed. It was designed explicitly to be easier to understand than its predecessor, Paxos, by splitting the problem into three separable pieces: leader election, log replication, and safety. That readability is a real feature — Raft powers the replicated logs behind etcd, Consul, and CockroachDB, in large part because implementers can actually reason about it.

The problem consensus solves

Any system that replicates data across multiple machines needs a way to agree on the order operations happened in, even when machines fail at inconvenient moments or messages arrive late or out of order. Without that agreement, replicas drift apart — one node applies an update the others never see, and now the “same” data means different things depending on which node you ask.

This is the same underlying problem explored in the CAP theorem: a distributed system can’t guarantee perfect consistency, availability, and partition tolerance simultaneously. Raft sits on the consistency side of that trade-off — it keeps a cluster in agreement even at some cost to availability during a leadership transition.

Roles: leader, follower, candidate

Every node in a Raft cluster is in one of three states:

• Leader. The single node currently responsible for accepting client requests and replicating them to the rest of the cluster. There is at most one leader at any given time.
• Follower. A passive node that accepts log entries from the leader and responds to its heartbeats. Most nodes are followers most of the time.
• Candidate. A transitional state a follower enters when it stops hearing from a leader and starts an election to become one.

Leader election

Raft divides time into numbered terms. Each follower keeps an election timer that resets every time it hears from the current leader. If that timer expires — because the leader crashed or a network partition cut it off — the follower becomes a candidate, increments the term number, votes for itself, and requests votes from every other node.

A candidate becomes leader once it collects votes from a majority of the cluster. Each node votes for at most one candidate per term, on a first-come, first-served basis, which is what prevents two nodes from both winning the same election. Randomizing each node’s election timeout is what keeps elections from splitting evenly and stalling: if every follower’s timer expired at the same instant, they’d all become candidates simultaneously and repeatedly tie.

Requiring a majority is also what keeps Raft safe during a network partition. If the cluster splits into two groups, only the group containing a majority of nodes can elect a leader and keep making progress — the minority side simply can’t collect enough votes, so it can’t diverge from the majority’s history.

Log replication

Once elected, a leader handles every write by appending it to its own log and then replicating that entry to its followers in parallel. An entry is considered committed — safe to apply and to acknowledge back to the client — only once a majority of nodes have stored it. This is the same majority-quorum idea used in consistent hashing-style distributed designs to tolerate partial failure without losing data: as long as more than half the cluster is reachable and healthy, the system keeps working.

Followers append entries in the exact order the leader sends them, and Raft guarantees that if two logs contain an entry with the same index and term, every entry before it is identical too. That property — log matching — is what lets a follower catch up safely after being partitioned or restarted: the leader just walks backward through the follower’s log until it finds the last point of agreement, then replays everything after it.

What happens when a leader fails

If a leader crashes, its followers stop receiving heartbeats, their election timers expire, and a new election begins. Any log entries the old leader had replicated to a majority before crashing are preserved, because the new leader must have those entries too — you can’t win an election without a log that’s at least as up to date as a majority of the cluster. Entries the old leader hadn’t yet replicated to a majority may be lost, which is the expected, documented behavior: an unacknowledged write was never guaranteed durable in the first place.

Raft versus other coordination approaches

	Raft	Two-phase commit	Gossip / eventual consistency
Goal	Strong agreement on an ordered log	Atomic commit across participants	Eventual convergence, no strict ordering
Availability during failure	Degrades until a new leader is elected	Blocks if the coordinator fails	Stays available, may serve stale data
Typical use	Replicated logs, configuration stores	Distributed transactions	Caches, membership lists, metrics

Raft solves a different problem than two-phase commit, which coordinates a single atomic transaction across independent participants rather than maintaining an ongoing replicated log. It’s also a stronger guarantee than the eventual consistency model that gossip-based systems rely on — Raft trades some availability during elections for a cluster that never disagrees about its own history.

Where you’ll run into it

Most engineers don’t implement Raft themselves — they rely on systems built on top of it. etcd (Kubernetes’ backing store), HashiCorp Consul, and CockroachDB’s range replication all use Raft to keep replicas in sync. If you’ve ever wondered how a Kubernetes cluster keeps a consistent view of its own state across multiple control-plane nodes, the answer, underneath etcd, is Raft.

The takeaway

Raft achieves distributed consensus by electing a single leader per term, requiring majority agreement before committing any log entry, and using randomized election timeouts to avoid split votes. That majority-quorum design is what lets a cluster tolerate node failures and network partitions without ever disagreeing about its own history — at the cost of a brief pause in availability whenever a new leader has to be elected.