Raft Consensus: Leader Election & Log Replication

Cluster

Network

Message latency 150 ms

Sim speed 1.0x

Client

Click any node in the diagram to isolate it from the network (a real partition) — click again to reconnect it.

Cluster State

Current leader

none

Term

Committed entries

In-flight msgs

Event Log

How this Raft simulation works

Every node is a real state machine: follower, candidate or leader, each with its own current term number. There is no scripted "leader wins" animation — the outcome is computed from real messages:

A follower that hears nothing from a leader before its randomized election timeout expires becomes a candidate, increments its term, votes for itself, and sends real RequestVote messages (amber dots) to every reachable peer, carrying real network latency.
A node grants at most one vote per term, and only if the candidate's log is at least as up to date as its own — the same log-completeness check real Raft uses to stop a stale node from becoming leader.
Once a candidate collects votes (green dots) from a real majority, it becomes leader and starts sending AppendEntries heartbeats (blue dots) so followers don't time out.
Propose Command appends a real log entry on the leader, which gets replicated to followers via AppendEntries. An entry only commits once a real majority of nodes have durably matched it — shown as filled boxes under each node.
Clicking a node partitions it: no message can be sent to or from it in either direction. Isolate a minority and the cluster keeps electing leaders and committing (availability wins). Isolate a majority (or split it near evenly) and no side can reach quorum — nothing commits until the partition heals, which is the real CAP-theorem trade-off Raft makes: it always protects consistency over availability during a partition.

RequestVote Vote granted Vote denied / fail AppendEntries Ack

click a node to isolate / reconnect it

Raft Consensus: Leader Election and Log Replication