Raft leader election · Log replication · Kill nodes · Network partitions · CAP theorem
This simulation visualises how a cluster of five nodes reaches agreement using the Raft consensus algorithm. Each node runs a randomised election timer, votes for a candidate, and once it gathers a quorum of three out of five votes it becomes the leader for a given term. The leader then replicates client commands as log entries through heartbeat and AppendEntries messages, so the whole cluster stays consistent even when individual nodes crash or the network splits.
A five-node Raft cluster animated on a canvas. Nodes cycle through follower, candidate and leader roles; election timers are drawn as filling arcs, and coloured dots represent RequestVote, Heartbeat and AppendEntries messages travelling between nodes. Election needs a majority quorum of three votes, and log entries only commit once a majority acknowledges them.
Pick an algorithm (Raft, Paxos or BFT) with the top buttons. Use "Append Log Entry" to have the leader replicate a command, "Network Partition" to split the cluster into [N1,N2,N3] and [N4,N5], and "Heal Partition" to reconnect it. Each node in the list has a Kill or Revive button, and "Reset Cluster" restarts the election from scratch.
Raft was designed in 2013 by Diego Ongaro and John Ousterhout specifically to be more understandable than Paxos, while providing the same fault-tolerance guarantees. It powers production systems such as etcd, Consul and CockroachDB.
Distributed consensus is the problem of getting many independent machines to agree on a single shared value or ordered sequence of commands, even when some machines fail or messages are lost. It is the foundation of fault-tolerant databases, configuration stores and replicated state machines, ensuring every healthy node ends up with the same committed log.
Every follower runs a randomised election timeout. When it expires without hearing from a leader, the node becomes a candidate, increments its term and requests votes. If it collects a quorum of three out of five votes it becomes leader and sends periodic heartbeats. The leader replicates new entries to followers and marks them committed once a majority acknowledges.
The algorithm buttons switch between Raft, Paxos and BFT and reset the cluster. Append Log Entry asks the current leader to replicate a command; Network Partition isolates nodes N4 and N5; and the Kill or Revive buttons crash or restore individual nodes. The stats panel reports the live leader, current term, committed entries, live node count, availability percentage and the required quorum.
Raft guarantees safety by requiring a majority quorum. When the cluster splits into [N1,N2,N3] and [N4,N5], only the side holding three or more nodes can elect a leader and commit entries. If the old leader ends up in the minority partition of two nodes, it can no longer reach a quorum, so the majority side elects a fresh leader for a higher term while the minority side stalls.
It captures the core mechanics accurately: terms, randomised election timeouts, majority voting, leader heartbeats, log replication and quorum-based commitment. For clarity it simplifies some details, such as full log-matching consistency checks, persistent storage, and the exact RPC retry logic, and the Paxos and BFT buttons are illustrative variants rather than separate full implementations.
This simulation models a five-node distributed cluster running the Raft consensus algorithm, which solves the fundamental problem of getting independent machines to agree on a shared, ordered log of commands even when nodes crash or networks partition. You can watch leader election unfold in real time as nodes exchange RequestVote and Heartbeat messages, observe how quorum (a majority of three out of five nodes) gates every commit, and experiment with node failures and network splits to see how the cluster recovers. Switching to Paxos or BFT modes illustrates alternative approaches to the same core challenge.
Distributed consensus algorithms underpin virtually every large-scale reliable system built today, from Google Spanner and Amazon DynamoDB to open-source stalwarts like etcd (which backs Kubernetes) and Apache Zookeeper, making this one of the most practically consequential topics in computer science.
The consensus problem asks how a set of independent processes, each with its own state and subject to failure, can reliably agree on a single value or sequence of decisions. A correct consensus protocol must satisfy three properties simultaneously: safety (all nodes that decide must decide the same value), liveness (the system must eventually make progress), and fault tolerance (the protocol must keep working despite a bounded number of node crashes or message losses).
When the page loads, all five nodes begin as followers with randomised election timers shown as filling yellow arcs around each circle. The first node whose timer expires becomes a candidate, sends RequestVote messages (yellow dots), and if it collects three votes it turns blue as the new leader. You can force a fresh election at any time by clicking Kill on the current leader and watching a new election begin automatically among the remaining nodes.
Clicking Network Partition isolates nodes N4 and N5 from N1, N2, and N3. Because Raft requires a quorum of three to commit any entry, the minority side (N4, N5) is frozen and cannot elect a leader or commit new commands. The majority side (N1, N2, N3) can still elect a leader and append entries normally. When you click Heal Partition, the isolated nodes rejoin, discover the higher-term leader, and synchronise their logs automatically.
A quorum is the minimum number of nodes that must participate in a decision to guarantee that any two quorums overlap by at least one node. For a cluster of N nodes the Raft quorum is floor(N/2) + 1. With five nodes that gives floor(5/2) + 1 = 3. This overlap property ensures that any two majorities share a node that has seen the most recent committed state, preventing two contradictory leaders from independently committing conflicting entries and breaking consistency.
Paxos, described by Leslie Lamport in his 1989 paper "The Part-Time Parliament" (published 1998), is often considered the canonical consensus algorithm but is notoriously hard to understand and implement completely because many practical details are left implicit. Raft, designed by Diego Ongaro and John Ousterhout and published in 2014, decomposes the problem into three largely independent sub-problems (leader election, log replication, and safety) and uses a single strong leader to simplify reasoning. Empirical studies have shown that students and engineers grasp Raft significantly faster than Paxos while the two provide equivalent fault-tolerance guarantees.
Byzantine faults are the most severe class of failures: a node does not merely crash and stay silent but sends actively incorrect, inconsistent, or malicious messages to different peers. A Byzantine Fault Tolerant (BFT) protocol, such as PBFT or the HotStuff variant used in many blockchains, can tolerate up to floor((N-1)/3) Byzantine nodes, requiring at least 3f+1 nodes to handle f traitors. This is more expensive than Raft's crash-fault tolerance (which only needs 2f+1 nodes for f crashes) but is essential in open, adversarial environments like blockchain networks where participants cannot be trusted.
Raft was created by Diego Ongaro as part of his PhD dissertation at Stanford University under advisor John Ousterhout. The foundational paper, "In Search of an Understandable Consensus Algorithm," was presented at USENIX ATC in June 2014 and won the Best Paper award. Ongaro's stated goal was explicit: design a consensus algorithm whose primary virtue is comprehensibility, making it easier for practitioners to build correct implementations compared to the dense formalism of Paxos.
Raft is used in etcd (the key-value store that is the backbone of Kubernetes cluster state), HashiCorp Consul (service mesh and configuration), CockroachDB and TiKV (distributed SQL), and InfluxDB. Paxos (or Paxos-derived protocols) underpins Google Chubby, Google Spanner, and Apache Zookeeper. Byzantine consensus variants power blockchain consensus engines such as Tendermint (Cosmos), HotStuff (Libra/Diem), and PBFT-based permissioned ledgers. Amazon DynamoDB uses a Raft-like approach for its internal replication groups.
A common misconception is that killing nodes might lose already-committed entries. In Raft this cannot happen as long as a quorum of nodes survives: an entry is only marked committed after the leader has received acknowledgement from a majority, and Raft's election safety property guarantees that any future leader must have at least one node from that majority in its own quorum, so it will always hold the committed entry. Data can only be durably lost if so many nodes fail simultaneously that no quorum survives — for five nodes that means losing three or more nodes at once.
Eric Brewer's CAP theorem (formalised by Gilbert and Lynch in 2002) states that a distributed system cannot simultaneously guarantee Consistency, Availability, and Partition tolerance: during a network partition you must choose one or the other. Raft and Paxos choose CP — during a partition the minority side becomes unavailable rather than risk serving stale or inconsistent data. Eventual-consistency stores like Apache Cassandra choose AP, remaining available during partitions but potentially serving stale reads. This simulator directly demonstrates the CP choice: the isolated N4/N5 partition stops serving requests rather than diverge from the majority.
Active research focuses on several directions: geo-distributed consensus with reduced latency using Flexible Paxos and WAN-optimised variants; leaderless protocols such as EPaxos and Atlas that allow any node to commit non-conflicting commands in parallel, eliminating the leader bottleneck; reconfiguration protocols that safely add or remove nodes without halting the system; and integration with hardware trusted execution environments (Intel TDX, AMD SEV) to reduce the cost of Byzantine fault tolerance. In the blockchain space, proof-of-stake BFT protocols like Ethereum's Gasper continue to evolve toward higher throughput and formal verifiability.