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.

Previously

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

  1. Watch
  2. Try it
  3. Predict
  4. Capture
Workload — etcd-style metadata store (3–5 servers, dataset KB–MB, linearizable admin reads, correctness > latency)Small dataset (kilobytes to megabytes). Linearizable admin reads are required. Low write throughput. Correctness beats latency in every trade. etcd's shipped defaults are tuned for exactly this shape — they are the canonical reference for the metadata-store workload.CLUSTERRF=3 · partitions=3S1 (leader)3PlogcommitIdxnoop@electS22Plogmatch[s2]S32Plogmatch[s3]READ MODE: READINDEX · MEMBERSHIP: SINGLE-SERVER · BATCH 10 MS (BALANCE… · 3 consumersclient (write) — election 1000…owns logclient (read) — ReadIndexowns commitIdxoperator — membership: single-…owns noop@electEOS LAYERONPIDproducer idEpochtxn epochGroup-Genrebalance genTRADE-OFFSThroughput3/5Durability3/5Complexity2/5WARNINGSPre-Vote + CheckQuorum on (scene raft-03a) — the trial-votesuppresses disruption from rejoining servers and the periodic …RF=3 matches the workload (scene raft-06: quorum = ⌊N/2⌋+1; RF=3tolerates 1).
What to watch for

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.

Implementation

Highlighted lines are the ones running in the diagram right now.

etcd-style metadata store
small dataset, linearizable admin reads, correctness > latency
# Workload: metadata store (etcd-style).
raftConfig = {
replication_factor: 3 or 5,
election_timeout_ms: 1000, # etcd default
heartbeat_interval_ms: 100, # etcd default
pre_vote: true, # scene 03a
check_quorum: true, # scene 03a
read_mode: "read_index", # scene 09 — correctness > latency
membership_change: "single_server", # scene 07
snapshot_every_entries: 10000, # scene 08
batch_window_ms: 10, # low write throughput
pipelining_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

Built with Arqly
Every scene in Build Raft — consensus you can defend builds on the one before it.All 12 Build Raft — consensus you can defend scenes