Raft is a consensus algorithm for keeping a replicated log in the same committed order across servers. A process still being alive as leader is not enough for safe progress: it needs to communicate with a cluster quorum. The Raft paper explains election, replication, and commit rules; the etcd glossary defines quorum as the active membership needed to modify cluster state.

The leader counts as a member of the quorum

For N members, quorum is floor(N/2)+1: two of three, or three of five. The leader is one of the cluster members and counts toward that total. In a three-node cluster, a leader and one follower that store the same log entry make a majority of two. The rule is not “a majority of followers in addition to the leader.”

This arithmetic also indicates how many unavailable members a cluster can tolerate while retaining a majority: three members can lose one, and five can lose two. A partition without a quorum cannot elect a new leader or safely commit a new change. A former leader process may remain alive on the minority side, but being alive does not grant it write authority.

Keep election terms and replication progress distinct

A Raft term is a logical epoch that separates elections. A candidate requests votes and becomes leader after a majority grants them. The leader then sends AppendEntries requests to replicate its log. Followers use term and log-consistency rules to decide whether to accept those entries. Election rules favor a candidate whose log is sufficiently up to date over one with an older log.

When diagnosing a cluster, inspect the current term, reachable member count, and the leader’s replicated index—not only the reported leader name. One slow follower can be tolerated while a majority remains connected; losing the majority should stop safe commitment of new changes.

The current-term rule controls commitment

A subtle rule prevents an unsafe shortcut: a leader cannot commit an entry from an earlier term merely because it sees that entry replicated on a majority. Under the Raft paper’s rule, the leader advances commitment by counting replicas for an entry from its current term. Once that entry is committed, preceding entries become committed indirectly through the log-matching property.

This handles entries a previous leader replicated but did not safely commit before losing leadership. “Present on more than half the nodes” and “committed for clients” are therefore not interchangeable. Do not infer a successful write from a replica count alone.

What a partition should look like

Consider three nodes, A, B, and C, with A initially the leader. If A loses contact with both B and C, A is alone in the minority partition while B and C remain connected as the two-node majority. B and C can elect a new leader and commit a current-term log entry replicated to their majority. Process A may still believe it is leader, but without quorum it cannot safely commit a new entry. When connectivity returns, A follows the higher term and conflicting uncommitted log entries are reconciled under Raft’s log-matching rules.

Before deployment, consider failure domains, network partitions, and membership configuration during restart—not just the number of processes. Raft supplies consensus rules; it does not replace application retries, idempotency, backup, or disaster-recovery procedures.

Sources