Raft Consensus: Leader, Terms & Log Replication

What it solves. To survive machine failures, state is copied to several nodes, and every copy must apply the same commands in the same order. That is consensus. Raft is a deliberately understandable alternative to Paxos and powers etcd, Consul and many databases.

Roles and terms. Each node is a follower, candidate or leader. Time is split into numbered terms; each term has at most one leader. A higher term always wins: any node seeing a higher term steps down to follower.

Leader election. A follower that hears no heartbeat for a randomised timeout (e.g. 150-300 ms) becomes a candidate, increments the term, votes for itself and asks the others for votes. Each node gives at most one vote per term, and only to a candidate whose log is at least as up to date as its own. A majority wins. Randomised timeouts make split votes rare and quickly resolved.

Log replication. Clients send commands to the leader, which appends them to its log and sends AppendEntries to followers. Each request carries the index and term of the entry just before the new ones; a follower rejects it if it does not have that previous entry, and the leader backs up and retries until the logs match.

Commit rule. Once an entry is stored on a majority, the leader marks it committed, applies it to its state machine, and tells followers (the commit index rides on later AppendEntries and heartbeats). Majority means a 3-node cluster tolerates 1 failure and a 5-node cluster tolerates 2.

Why it is safe. Two majorities always overlap in at least one node. A candidate cannot win without a log containing every committed entry, because at least one voter in its majority holds those entries and refuses a less up-to-date candidate. So a committed entry is never lost by a leader change.

Partitions. A leader cut off from the majority cannot commit anything (it cannot reach a majority), and the majority side elects a new leader with a higher term. When the partition heals, the old leader sees the higher term, steps down, and its uncommitted entries are overwritten.

Practical notes. Reads that must be fresh go through the leader (or confirm leadership first), or you accept follower reads that may be slightly stale. Logs are compacted with snapshots. Odd cluster sizes (3 or 5) are standard because a 4th node adds cost but no extra fault tolerance over 3.