Raft Consensus Protocol: Leader Election, Log Replication, and Split-Brain Safety

Written by: TrendSpike Engineering Desk  |  Published: October 9, 2026  |  Topic: Distributed Systems & Consensus Algorithms

In distributed databases and coordinated service clusters such as etcd, Consul, and distributed storage systems, multiple machines must maintain a consistent view of replicated state. Network failures, crashed nodes, and delayed messages can cause replicas to temporarily diverge, so the system needs a protocol that determines which operations become committed and in what order.

The Raft consensus protocol, introduced by Diego Ongaro and John Ousterhout, was designed as an understandable approach to replicated-state-machine consensus. Raft separates the consensus process into major components including leader election, log replication, and safety rules for maintaining a consistent replicated log.

1. Cluster Roles and State Transitions

Raft does not require a cluster to contain an odd number of nodes, but odd-sized clusters are commonly used because they provide more failure tolerance per member than the next larger even-sized cluster. For example, a 5-node cluster requires a majority of 3 nodes and can continue making progress with up to 2 nodes unavailable, assuming the remaining members can communicate normally.

At any given time, each Raft server is in one of three primary states:

• Leader: The leader handles client requests that require consensus, appends commands to its log, and replicates log entries to followers. It also sends periodic AppendEntries messages, including empty heartbeats, to maintain its authority.
• Follower: A follower responds to RPCs from leaders and candidates. If it stops receiving valid leader communication for its configured election timeout, it can transition to candidate state and begin an election.
• Candidate: A candidate is a server seeking leadership for a new term. It increments its term, votes for itself, and requests votes from other servers.

2. Leader Election and Randomized Timeouts

Raft divides time into numbered terms. A term normally begins with an election, and the term number helps servers distinguish current messages and leaders from stale ones.

The election mechanism relies on several core rules:

• Heartbeat Monitoring: Followers expect periodic AppendEntries RPCs from the current leader. If a follower receives no valid leader communication during its configured election timeout, it assumes that a leader may be unavailable and begins an election.
• Randomized Timeouts: Raft uses randomized election timeouts to reduce the probability that multiple servers become candidates simultaneously. The original Raft paper gives 150–300 ms as an example election-timeout range; actual implementations can use different values based on their timing and network requirements.
• Majority Quorum Requirement: A candidate becomes leader after receiving votes from a majority of the servers in the cluster for the same term. In a 5-node cluster, this requires at least 3 votes. A server grants at most one vote in a given term, subject to Raft's voting rules.
• Log Freshness Rule: A server does not grant its vote to a candidate whose log is less up-to-date than its own. Raft compares the term of the candidate's last log entry first; if those terms are equal, it compares the last-log index. This voting restriction helps ensure that an elected leader contains all committed entries from previous terms.

3. Log Replication Mechanics

After a leader is elected, client commands are replicated through the leader's log:

1. Ingress: A client submits a command to the leader. The leader appends the command as a new log entry and records the current term in that entry.
2. Replication: The leader sends AppendEntries RPCs to followers. The RPC identifies the log index and term of the entry immediately preceding the new entries so that the follower can verify log consistency.
3. Consistency Check: A follower accepts the new entries only if its log contains the preceding entry with the required index and term. If the consistency check fails, the leader adjusts its replication position for that follower and retries. When conflicting uncommitted entries are encountered, the follower can delete those conflicting entries and accept the leader's entries.
4. Commitment: An entry becomes committed when Raft's commitment rules are satisfied, including replication to a majority of the cluster. The leader then advances its commit index and applies committed entries to its state machine. Implementations such as etcd persist Raft log entries to durable storage as part of their reliability model.

Raft also imposes an important safety rule on commitment: a leader normally uses replication of an entry from its current term to a majority to establish commitment. Once an entry is committed, later leaders must preserve it.

4. Split-Brain Mitigation and Network Partitions

A network partition can divide a cluster into disconnected groups. Raft's majority-quorum requirement prevents a minority partition from independently committing conflicting cluster state.

Consider a 5-node cluster partitioned into a 2-node minority partition and a 3-node majority partition:

• The Minority Partition: If the old leader is isolated with only one other node, it does not have a majority of the five-node cluster. It therefore cannot commit new log entries that require cluster consensus.
• The Majority Partition: The three-node partition contains a majority of the original cluster. If an election is triggered and a candidate satisfies Raft's voting and log-freshness rules, the majority can elect a new leader and continue committing entries.
• Rejoining the Cluster: When the partition heals, a server that discovers a higher term updates its term and steps down to follower state. If its log contains entries that conflict with the current leader's log, those uncommitted conflicting entries can be deleted and replaced through log replication. Committed entries are protected by Raft's safety rules.

5. Why Quorum Prevents Two Leaders from Committing Conflicting State

Raft's quorum model is central to its safety properties. Any two majorities of the same cluster must overlap in at least one server. Because a server can grant at most one vote in a given term, two different candidates cannot both obtain a majority for the same term.

The same majority principle also prevents a minority network partition from independently committing new cluster state. A partitioned leader may continue to hold uncommitted log entries, but without a quorum it cannot advance the cluster's committed state.

Sources & Official References

• Ongaro & Ousterhout: In Search of an Understandable Consensus Algorithm (Original Raft Paper)
• etcd v3.7 Documentation: Official Documentation
• etcd Documentation: Persistent Storage and Raft WAL
• etcd v3.7 FAQ: Quorum, Failure Tolerance, and Raft
• Raft Consensus Algorithm: Official Project Portal

Disclaimer: This article explains distributed-systems architecture for informational and educational purposes. Production implementations such as etcd may include additional mechanisms and operational features, including persistence, snapshots, log compaction, pre-vote behavior, and membership reconfiguration.