Build Raft — consensus you can defend (12 scenes)
Scene 11 · Design your Raft deployment
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.
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
Diagram
TOP: the workload card — what this Raft cluster is being asked to do (dataset shape, read requirements, failure-tolerance target, latency budget). MIDDLE: the cluster as you have configured it — N servers (S1 the leader, others followers), each annotated with the per-server state from earlier scenes (log, commitIndex, matchIndex, the no-op-on-election entry from scene 10). BOTTOM-LEFT: the trade-off bars (throughput / durability / complexity) — the same axes every distributed-systems design review uses. BOTTOM-RIGHT: the VERIFIER — every knob choice is annotated against the earlier scene whose insight justifies (info) or contradicts (warn / danger) it. RIGHT COLUMN: the safety floor (Pre-Vote, CheckQuorum, no-op-on-election) — production Raft requires all three, regardless of workload (scenes raft-03a + raft-10).
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).
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
etcd-style metadata store
small dataset, linearizable admin reads, correctness > latency
1# Workload: metadata store (etcd-style).
2raftConfig = {
3 replication_factor: 3 or 5,
4 election_timeout_ms: 1000, # etcd default
5 heartbeat_interval_ms: 100, # etcd default
6 pre_vote: true, # scene 03a
7 check_quorum: true, # scene 03a
8 read_mode: "read_index", # scene 09 — correctness > latency
9 membership_change: "single_server", # scene 07
10 snapshot_every_entries: 10000, # scene 08
11 batch_window_ms: 10, # low write throughput
12 pipelining_max_inflight: 64, # small dataset
13}