Interactive Raft Consensus Algorithm Visualizer

This page is a live, in-browser simulator of Raft, the consensus algorithm that keeps a cluster of servers agreeing on a single ordered log even while machines crash and the network misbehaves. Raft powers etcd, Consul, TiKV, CockroachDB and many other systems. Watching it run — leader election, heartbeats, log repair — is a much faster way to understand it than reading Figure 2 of the paper cold.

What the Raft algorithm actually does

Every node is a follower, a candidate or the leader. Time is divided into numbered terms, and each term has at most one leader. The leader accepts client commands, appends them to its log, and replicates them to everyone else. A command is committed once a majority of the cluster has stored it — at which point it can never be lost, even if the leader dies the moment after.

Leader election, step by step

Each follower runs a randomized election timeout. If no heartbeat arrives before it fires, that node bumps currentTerm, votes for itself, becomes a candidate and sends RequestVote to every peer. A node grants its vote at most once per term, and only to a candidate whose log is at least as up to date as its own. Win a majority and you are leader; the winner immediately starts sending AppendEntries heartbeats to shut down every rival timer.

When two nodes time out simultaneously the result is a split vote: neither reaches quorum, the term is wasted, and the randomized timeouts resolve it on the next attempt. The Split vote scenario on this page forces that situation on purpose so you can watch a whole term go nowhere.

Log replication and log repair

AppendEntries carries prevLogIndex and prevLogTerm. A follower rejects the message unless its own log matches at that position, so the leader walks nextIndex backwards until it finds the last point of agreement, then overwrites the follower's divergent tail. The Stale follower repair scenario stages a follower holding four entries from a dead leader's term and lets you step through the backtracking and truncation one message at a time.

The subtlest rule in Raft is that a leader may only commit an entry from its own term. The Figure 8 scenario shows an old entry replicated to all five nodes that still stays uncommitted — until a fresh command in the current term commits both at once. Getting this rule wrong is how implementations silently lose committed data.

Break the cluster: crashes, partitions and one-way links

• Crash a node — click it. currentTerm, votedFor and the log survive the restart, because Raft requires those to be persistent.
• Partition the network — split the cluster into groups. The majority side keeps committing; the minority side spins its term upward and commits nothing.
• Cut a single link, in one direction — click the wire between two nodes to cycle it through healthy, fully cut, and each one-way state. A node that can send but not receive times out forever and keeps disrupting a perfectly healthy leader. Turn on PreVote and watch the disruption stop.
• Degrade it — packet loss up to 60% and latency jitter up to ±80%. Dropped messages die visibly in flight with the reason attached.

Two-phase commit on top of Raft

The second view, 2PC over Raft, runs a distributed transaction across several Raft groups at once — a coordinator group plus one to three participant shards, each of them a full cluster with its own leader, term and log. Two-phase commit is how a database makes one transaction atomic across machines that do not share storage: the coordinator sends PREPARE, every participant answers PREPARED or refuses, and only then does the coordinator announce COMMIT or ABORT.

Textbook 2PC has one notorious flaw, and you can reproduce it here in about twenty seconds. Turn Replicated coordinator off so the coordinator is a single machine, start a transaction, and crash it once both shards show a lock. Every participant has promised it can commit, none of them is allowed to guess, and the only node that could release them is gone. Nothing times out. Nothing recovers. That is the blocking problem, and retrying harder does not fix it.

The fix, from Gray and Lamport's Consensus on Transaction Commit, is to stop writing the decision to one disk and start committing it to a consensus group — which is what Spanner does, running 2PC across Paxos groups. Turn the toggle back on and every 2PC record here becomes an ordinary Raft log entry: the coordinator will not send a single PREPARE until BEGIN is on a majority of its own group, and no shard answers until its own vote is committed by its own group. Watch the row of boxes under each bubble — faded and dashed while the record is merely written, solid once it is durable. Nothing is ever said out loud before its box goes solid. Now crash the coordinator's leader again: a new one is elected, reads the decision straight out of the replicated log, and finishes the transaction the dead machine started. Crash a shard leader the instant its vote commits and the same thing happens on the other side — its replacement answers PREPARED for a transaction it has never heard of.

Using the controls

Pick a scenario, then pause and use Step (120 ms) or Next event to advance one message at a time; drop the speed to 0.5× for the repair walkthrough. Hover any in-flight message to inspect the full RPC payload. Client command appends a new entry at the leader. The explanation panel narrates the current phase and the reasoning behind it, and the log panel records every state transition, vote and commit.

The View bar at the top switches between the single cluster and the 2PC view; whichever one you are not watching is paused where you left it. In the 2PC view the topology is yours to change: pick a group and add or remove nodes — up to seven, down to one — and its log survives the resize, so you can grow a group in the middle of a live transaction and watch its quorum change under it. Adding or removing whole shards rebuilds them, so that discards the transaction in progress and says so in the log. Packet loss, jitter, PreVote and the leader no-op apply to every group at once.

Is the simulation correct?

It implements Figure 2 of the paper rather than animating a hand-waved state machine, and a headless test suite drives the same engine the browser runs, asserting Raft's four safety properties — Election Safety, Log Matching, State Machine Safety and Leader Completeness — after every simulated tick under randomized crashes, partitions, link cuts and packet loss. The 2PC layer is checked the same way, per group and on top: no two shards may reach opposite outcomes, a committed decision may never change, and no shard may apply anything the coordinator has not committed. One row is a deliberate negative control — with an unreplicated coordinator the transaction must block, or the rows proving that replication rescues it would prove nothing. Known simplifications: no log compaction or snapshots, no joint consensus for membership changes, one transaction at a time, and presumed abort with no cooperative termination protocol — participants never ask each other how it ended, because the blocking is the point.

Built by raminshiraz · source and full notes on GitHub · based on In Search of an Understandable Consensus Algorithm by Diego Ongaro and John Ousterhout (USENIX ATC 2014). MIT licensed.