RAFT · REQUEST · VOTE · ELECT
Raft leader election
Follow local terms and real vote certificates through failures and recovery.
Messages delivered this tick
Exact election evidence
Inspect pending messages and vote certificates
Inspect an election rather than a promotion
Five fixed members require three votes to elect a leader. Each node has its own current term, role, vote choice and election deadline. A timeout creates a candidate in its next term, records its self-vote and sends vote requests. The candidate becomes leader only after receiving enough distinct granted votes for that term. The vote certificate lists those voters. Node zero begins as an already elected term-one leader; the initial certificate is an explicit starting condition, not a newly simulated election. No client command is committed by this lab.
Configure failures and timing
Failure scenario selects no failure, a crash of node zero at tick three, or a network split at tick three separating nodes zero and one from nodes two, three and four. Heal at tick restores that connection at the selected tick; sixty-one leaves it split for the entire sixty-tick trace. A crashed node stays down. Base timeout sets the minimum election wait. Randomized timeouts adds a seeded offset smaller than that base; disabling it gives every node the same wait. Message delay is the number of ticks between sending and delivery. Scenario seed changes the reproducible deadline choices. Each edit rebuilds the scenario and pauses at the beginning.
Follow the default crash
Restore defaults selects seed forty-two, base timeout eight, message delay one and randomized deadlines. Inspect tick three: node zero is down, but the remaining nodes have not automatically promoted anyone. At tick thirteen, node one has collected votes from itself, node two and node four and becomes the new term-two leader in this fixture. Inspect earlier ticks to find its RequestVote messages and the returned grants. Change the seed or delay and compare the winning node and election time. Those outcomes depend on this deterministic schedule; the default winner is not a protocol guarantee.
Create split votes and reject stale candidates
Disable randomized timeouts under the crash scenario. Followers repeatedly begin elections together, keep their own votes and fail to collect a majority within this trace. Re-enable randomization to break that symmetry. Enable Stale log at node one: its last-log term and index become zero while other nodes retain one. The message evidence then shows fresher nodes refusing its requests. This fixture checks candidate log freshness but does not copy or repair logs. A later heartbeat does not magically update that stale metadata. The experiment separates eligibility to win an election from the distinct job of log replication.
Observe an old leader behind a partition
Select the partition scenario with healing at sixty-one. The majority group can elect a new leader in a higher term, while node zero may still call itself leader in the isolated minority. The page deliberately displays both local beliefs rather than pretending every node immediately knows the global situation. Their terms differ; there is never more than one elected leader in the same term. Set healing to thirty and inspect subsequent deliveries: learning the higher term makes the old leader step down. This does not mean its earlier minority-side client writes were committed; client writes are outside this model.
Read messages at your own pace
Play advances sixty logical ticks over sixty inspection seconds. Pause holds the current prefix; Next tick advances one tick; Restart rewinds the same scenario; Speed changes viewing pace; Inspect time scrubs; Show final tick jumps to the end. Node cards show local roles, terms, vote choices, collected voters and log metadata. The event list names actual vote requests, grants, rejections, dropped messages and elections. The expandable evidence includes the full selected state and pending messages. Timing is a teaching schedule, not measured milliseconds. There are no snapshots, membership changes, client proposals, durable-storage faults or full AppendEntries log matching. Heartbeats here maintain election timers and exchange terms; this election-only model cannot establish replicated-log safety or predict production failover latency.
Protocol reference: Ongaro and Ousterhout, the Raft paper.