Consensus Algorithms (Raft Simplified)

📘 Chapter 9: Consistency & Distributed Consensus ⏱️ 10 min read 🏗️ Lesson 038

How do distributed nodes agree on a value when some may fail or become unreachable? This is the consensus problem — and it's the foundation of leader election, distributed locks, configuration management, and replicated state machines. Raft was designed in 2014 specifically to be understandable, unlike its predecessor Paxos.

Why Consensus Matters

You Need Consensus For:

  • Leader election: Which node is the primary? All must agree.
  • Configuration management: What's the current cluster membership?
  • Distributed locks: Who holds the lock right now?
  • Replicated state machines: Ensuring all replicas apply the same operations in the same order.

Without consensus, you get split-brain: two nodes both think they're the leader, accept conflicting writes, and corrupt your data.

Raft's Three Roles

  • Leader: Handles all client requests. Replicates log entries to followers. Only one leader per term.
  • Follower: Passive — responds to RPCs from leader and candidates. If it doesn't hear from a leader, it becomes a candidate.
  • Candidate: Transitional state during an election. Requests votes from other nodes.
Raft State Machine — Role Transitions Follower Passive, listens Candidate Requests votes Leader Handles requests election timeout wins majority discovers leader higher term discovered split vote → new term ← all nodes start here
Figure 1: Raft state machine. Nodes transition between Follower, Candidate, and Leader roles based on timeouts and vote outcomes.

Leader Election

The Election Process

  1. Each follower has a randomized election timeout (150-300ms). If no heartbeat from leader → timeout fires.
  2. Follower increments its term number and becomes a Candidate.
  3. Candidate votes for itself and sends RequestVote RPCs to all other nodes.
  4. Other nodes vote YES if they haven't voted in this term and the candidate's log is at least as up-to-date.
  5. If candidate gets votes from a majority (⌈N/2⌉ + 1) → becomes Leader.
  6. Leader immediately sends heartbeats to prevent new elections.

Randomized timeouts prevent split votes: nodes wake up at different times, so usually one starts the election first and wins quickly.

Log Replication

Once elected, the leader handles all writes. It appends entries to its log, replicates them to followers, and commits once a majority acknowledges.

Log Replication in a 5-Node Cluster Leader x=1 y=5 z=3 ← new entry (uncommitted) Node 2 x=1 y=5 z=3 ✓ Node 3 x=1 y=5 z=3 ✓ Node 4 x=1 y=5 pending... Node 5 x=1 y=5 ✗ unreachable Majority reached! (3/5) Leader + Node 2 + Node 3 = 3 ACKs → Entry "z=3" is now COMMITTED Committed entries are durable — even if the leader crashes, a new leader will have this entry.
Figure 2: The leader replicates entry "z=3" to followers. Once 3 of 5 nodes have it (majority), the entry is committed.

Safety Guarantees

What Raft Guarantees

  • Election Safety: At most one leader per term.
  • Leader Append-Only: A leader never overwrites or deletes entries in its log.
  • Log Matching: If two logs contain an entry with the same index and term, all preceding entries are identical.
  • Leader Completeness: If an entry is committed, it will be present in the log of all future leaders.
  • State Machine Safety: If a node applies an entry at a given index, no other node will apply a different entry at that index.

These guarantees together ensure that committed entries are never lost, even through leader failures.

Real-World Systems Using Raft

🏢 etcd — Kubernetes' Brain

etcd is the key-value store that holds all Kubernetes cluster state: pod definitions, service configs, secrets, node membership.

  • Uses Raft for consensus across typically 3 or 5 etcd nodes
  • Every kubectl apply ultimately writes to etcd through Raft
  • If the etcd leader dies, a new election happens in ~150-300ms
  • Writes require majority acknowledgment → consistent cluster state

🏢 CockroachDB — Multi-Region Consistency

CockroachDB uses Raft at the range level (each range of data has its own Raft group):

  • Data is split into ranges (~64MB each), each replicated via its own Raft group
  • Thousands of concurrent Raft groups per node
  • Enables strong consistency within each range while distributing load across the cluster
  • Leader leases optimize reads (leader can serve reads locally without consensus round-trip)

Interactive: Raft Cluster Simulation

A 5-node Raft cluster. Kill the leader and watch an election happen: