This trace follows the actual state transitions behind the companion Raft Uses Terms and Quorums to Choose a Leader. It describes a common execution path; implementation details can vary, so keep the contract separate from the mechanism.
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.
At this point, record the state that changed and check the invariant before advancing. If the operation repeats, make clear which values persist and which are recomputed.
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 complete when the result satisfies the stated contract. Compare this model with the concrete runtime or system you are studying before making a performance claim.