hardraft-reference#quorum#leader-election#replicated-log

Run a Raft Failure Tabletop

Use a three-node cluster to reason about elections, log replication, quorum loss, and which client outcomes remain uncertain.

The Runtime Theory TeamSeptember 25, 20261 min read

Solve it

Solving happens on the judge — come back and mark it done

Sample cases

in3-node cluster; leader and one follower persist entry; third node is partitioned

outA majority has the entry, subject to Raft's term and commit-index rules

in3-node cluster splits into one node and two nodes

outThe majority side can elect a leader; the isolated node cannot commit new entries

inLeader replies after commit, then crashes

outA later leader preserves committed entries under Raft's safety rules

Draw three servers with terms, log indexes, commit indexes, and a client command. For each scenario, mark which messages arrive, which server can lead, and whether the command is merely appended or committed.

Use a majority quorum and the Raft paper's current-term and log-matching rules. Then answer what the client can know if its request times out after the leader replicated the command but before the reply arrives. Distinguish protocol safety from application-level duplicate handling.

The linked Raft site collects the paper and related resources. Do not assume a single visualization captures every membership-change or snapshot rule.

One dispatch a week

The trace behind each problem, the tradeoff that explains it, and one technical dispatch per week — no noise.

One technical dispatch per week. No noise.

Not started