Design your Raft deployment
You've now seen every mechanism Raft uses to stay safe and live. Time to apply them. The same protocol commits to radically different settings on every knob depending on the workload — and the verifier traces each choice back to the scene that defends it.
Scene 10 named every operational reality (no-op-on-election, pipelining, batching, the fsync-stall failure mode, leadership transfer). With every primitive now defended, here is the canvas: three real workloads, one protocol, three radically different placements.
Scene 11
Design canvas — three workloads, one protocol
- Watch
- Try it
- Predict
- Capture
You've now seen every mechanism Raft uses to stay safe and live. The canvas starts on the etcd-style metadata store: 3 servers, 1000ms election timeout, ReadIndex (not lease), single-server membership, snapshots every 10K entries, Pre-Vote + CheckQuorum on. Each placement on the canvas is annotated with the scene that defends it. Continue to size all three workloads.
Highlighted lines are the ones running in the diagram right now.
# Workload: metadata store (etcd-style).raftConfig = {replication_factor: 3 or 5,election_timeout_ms: 1000, # etcd defaultheartbeat_interval_ms: 100, # etcd defaultpre_vote: true, # scene 03acheck_quorum: true, # scene 03aread_mode: "read_index", # scene 09 — correctness > latencymembership_change: "single_server", # scene 07snapshot_every_entries: 10000, # scene 08batch_window_ms: 10, # low write throughputpipelining_max_inflight: 64, # small dataset}
Where this sits in Build Raft — consensus you can defend
Scene 11 of 12. Capstone: pick election timeout, batch window, RF, read mode, membership-change strategy, snapshot cadence for three workloads — etcd metadata, Cockroach-style txn-KV with lease reads, queue manager. The verifier traces every knob back to the scene that defends it.
All 12 scenes in Build Raft — consensus you can defend · Every curriculum