Raft Log Replication and Commit Lab (Interactive)
Write through a five-node Raft group, kill the leader, watch election rules pick the successor. Replicate client writes to majority, crash nodes, and see the election restriction and conflict truncation keep every replicated log identical once committed.
Raft Log Replication & Failover Bench
Replicate client writes to a majority, kill the leader, and watch the election-safety rule decide who may commit next.
How It Works Under the Hood
Raft decomposes consensus into leader election, log replication, and safety: clients write to the leader, entries fan out to followers, and an entry commits once a majority of the current term acknowledges it — after which it is durable and applied identically everywhere. Leadership can move, so Raft restricts votes to nodes whose log is at least as complete (last term, then length), and a new leader force-overwrites followers’ conflicting uncommitted suffixes. This lab shows per-node log chips in amber until commitment, triggers elections when the leader dies, and counts exactly which uncommitted entries the cluster discards on the way to convergence.
Core Architectural Principles
- Commit rule: an entry is durable only when a majority of the current term holds it.
- Election restriction: candidates with shorter or older logs cannot win the vote.
- New leader force-truncates conflicting uncommitted suffixes — committed entries never vanish.
Contrast with Paxos pragmatically: “Raft elects a leader first so replication is one round trip, and its leadership plus log-matching rules are legible enough to verify.” Be ready to explain why an old-term entry cannot commit alone and why the leader is the one node allowed to truncate followers.
Single-leader Raft is understandable and strongly consistent, but every write still crosses a majority before ack.