This trace follows the actual state transitions behind the companion Raft Uses Terms and Quorums to Choose a Leader. Each step below names its concrete inputs; values illustrate the mechanism and vary across implementations.
Step 1: Start a term and election
Consensus lets a group of processes agree on an ordered sequence of decisions despite specified failures. Raft separates leader election, log replication, and safety rules into understandable mechanisms. It assumes crash failures and a communication network that can delay, drop, or reorder messages.
Step 2: Collect a majority of votes
Each server tracks a current term. A candidate requests votes; a server grants at most one vote per term under the protocol’s log-freshness rule. A leader appends client commands to its log and considers an entry committed once the required majority has replicated it, subject to Raft’s commit rules.
Step 3: Append a command to the log
A leader advances the commit index when Raft’s quorum and term conditions hold; a local append alone is not enough to promise the command is committed.
Checkpoint: A leader advances the commit index when Raft’s quorum and term conditions hold; a local append alone is not enough to promise the command is committed. Confirm this state before advancing to Replicate and commit by quorum.
Step 4: Replicate and commit by quorum
A majority quorum tolerates some unavailable servers but cannot make progress if a majority cannot communicate. Network partitions may create temporary competing leaders in different terms, while safety rules prevent committed history from being overwritten. Consensus does not solve application-level deduplication or external side effects.
Step 5: Reply under the commit rule
In a five-server group, how many servers form a majority? What happens to write availability if three servers are mutually isolated from the remaining two?
The trace is done when this check holds: In a five-server group, how many servers form a majority? Compare the outcome against the companion article before making a performance claim.
Hardware, runtime, and observability notes
When tracing Trace: Raft Uses Terms and Quorums to Choose a Leader in a live production environment (subsystem: distributed-systems, primary layer: system), keep the following step-level cost model and diagnostic checklist in mind:
- Step 1 (system): Start a term and election — verifies state invariants before advancing the execution pointer.
- Step 2 (system): Collect a majority of votes — verifies state invariants before advancing the execution pointer.
- Step 3 (system): Append a command to the log — verifies state invariants before advancing the execution pointer.
- Step 4 (system): Replicate and commit by quorum — verifies state invariants before advancing the execution pointer.
- Step 5 (system): Reply under the commit rule — verifies state invariants before advancing the execution pointer.
Every transition across the system boundary carries both a direct CPU/memory cost (cache-line fills, descriptor lookups, lock acquisitions, or context switches) and a tail-latency queueing risk under contention. To verify this trace on your own service, capture latency histograms and hardware/kernel counters across each step boundary, compare cold-cache versus warm-cache execution paths, and confirm that error or timeout branches release all acquired descriptors, locks, and buffers cleanly.