Raft roles, terms, and why majority quorums prevent split brain

Your Kubernetes cluster is backed by a 5-node etcd cluster. One node loses power mid-morning. You run kubectl get pods and it works fine — no error, no stall. How is there still agreement with a node down?

The job: one machine from many

A distributed system’s hardest problem is agreement. If five nodes each accept writes independently, you get five conflicting histories. Raft’s job is to make those five nodes behave like one: same order of changes, same state, no writes lost. It does this by electing exactly one leader at a time and routing all changes through that leader.

Three roles

Every Raft node is in exactly one of three states:

• Follower — the default state. Receives and stores log entries from the leader. Does not accept client writes directly.
• Candidate — a follower that has stopped hearing from a leader and is now running for leadership. Temporary state, lasts until the election resolves.
• Leader — the node clients send writes to. Drives replication to all followers. At most one leader per term exists in a healthy cluster.

A node starts as a follower. It becomes a candidate when its election timeout fires. It becomes a leader if it wins a majority vote.

The term: a monotonic logical clock

Raft tracks time not with wall clocks but with terms — monotonically increasing integers. Each term begins with an election. If a leader wins, it leads for the whole term. If no leader emerges (split vote), the term ends and a new one starts.

The term has two jobs:

1. Deduplication. When a message arrives, nodes compare the sender’s term to their own. A higher term always wins — the receiver updates its term and steps down to follower if needed. This resolves stale-leader confusion instantly.
2. Ordering. Every log entry is tagged with the term it was written in. This tag is used later to detect log divergence.

Terms are never reused. If you see term 7, every message from term 6 is stale.

Majority quorum: the split-brain barrier

Raft requires a majority (more than half the cluster) for two operations: elections and commits. In a 5-node cluster the majority is 3.

Why majority specifically? The key property is overlap: any two majorities of the same set share at least one node. In a 5-node cluster, if one set of 3 commits an entry and a different set of 3 elects a new leader, those two sets cannot be disjoint — they share a node. Through that shared node, the new leader is guaranteed to have seen the committed entry.

If Raft used simple plurality (2 of 5) instead of majority, two separate groups of 2 could each believe they are authoritative — split brain. Majority prevents this.

Failure tolerance: a cluster of N nodes tolerates floor((N-1)/2) simultaneous failures. 5 nodes → 2 failures. 3 nodes → 1 failure. This is why Raft clusters are 3, 5, or 7 nodes — odd numbers maximize tolerance for a given size.