← lab

Kill the leader

Five real Web Workers on your CPU, each running the Raft consensus protocol — election timeouts, RequestVote, AppendEntries, term rules, the safety checks. They elect a leader among themselves. The button below calls worker.terminate() on whichever one won: an operating-system thread dies, and the survivors have to notice and elect again.

The recovery time is measured, not animated. It is different every click because it is bounded by randomised timeouts running on your silicon. Open DevTools → Sources → Threads and watch one disappear.

safety invariants: 500/500 schedules pass in CI · nothing violated in this session
cluster
committed 0

A majority is more than half the ring. Below it, a correct cluster stops.

Nobody is in charge until one of them is elected. Press the button and watch it happen. Keep pressing: at three of five the margin is zero, and at two the cluster correctly refuses to elect or commit anything.

term0
leader
alive
quorum needs
committed entries0

The last recovery, decomposed

One number is a demo; the decomposition is the finding. Everything here comes from performance.mark(), so you can check it in DevTools → Performance without this page's cooperation.

total recovery
detect
campaign
first append
term
votes
winner
committed entries lost
of the wall clock was detection.
Want this measured on your infrastructure? → €490 architecture audit

Distribution over this session

A single recovery number proves nothing. Click the button repeatedly.

runs0
median
fastest
slowest

The wire

messages sent
0
delivered
0
dropped
0
reordered
0
in flight
0
measured frame jitter
real postMessage hop
injected link τ

Link delay is derived from your own measured frame jitter. That is why the recovery number differs between two machines, and between two runs on one machine.

This run

seed
nodes
quorum
logical cores reported
timeout ladder
partition
link latency
message loss
reduced motion

Attack it

Every parameter is a URL parameter, so any run you find is a link you can send back to me.

?seed=20672
pin the seed — replays one exact election ladder forever
?partition=3,4
cut nodes 3 and 4 off from the rest. The minority must refuse to elect
?latency=180
pin link delay to 180 ms and force churn
?loss=0.05
drop 5% of messages, deterministically under the seed
?indep=1
independent random timeouts instead of the φ-jittered ladder — split votes go up

Honest scope: no snapshotting, no membership changes, no persistence across reload. Five workers, one CPU, a real protocol at toy scale. The safety invariants (election safety, leader completeness, log matching, state-machine safety, no commit without a majority) are gated in CI over 500 randomised fault schedules and block the deploy if any of them fails.

Event feed