Commitment: preserve the current-term rule before applying

The last-log index describes what is locally stored. The commit index describes the highest prefix position this server knows is committed. The applied index describes how far its state machine has executed that committed sequence. A node can have a long speculative suffix, a shorter committed prefix, and an even shorter applied prefix. Exporting one generic replication index obscures these distinctions. When a read appears stale, inspect whether the delay lies in agreement, notification of commitment, or actual state-machine execution.

Application advances in index order through committed commands, not in the order network acknowledgements happen to arrive. A deterministic state machine produces the same state from the same starting snapshot and command sequence. If commands depend on nondeterministic local time, random values, or external service replies, those choices need to be represented consistently in the agreed input or handled by a separate design. Agreement on command bytes alone does not force replicas to make identical uncontrolled external observations.

For a fixed-membership leader in term T, choose a candidate index N beyond its current commit index. The basic Raft rule requires that a majority's match indices reach N and that the leader's log entry at N has term T. Successful durable acknowledgements, including the leader's own appropriately persisted copy, support that count. Once N satisfies the rule, entries through N become committed. Previously committed entries do not become uncommitted merely because the leader later loses contact with a majority.

The extra term condition prevents an unsafe inference about old entries surviving earlier leadership changes. An older entry may have accumulated copies across terms without the election restriction yet ruling out a competing higher-term suffix. Commit a new current-term entry, often a no-op, and log matching ties the older prefix to that new committed entry. This explanation is specific to Raft's rule for retaining original entry terms; do not transfer it mechanically to a differently proved Paxos log protocol.

A client expecting an operation result generally needs the committed command applied and its result associated with its request identity. A leader may crash after application but before responding, so the replacement must recover the deduplication state needed to avoid performing the same logical action twice. External side effects add another boundary: a log entry instructing a payment does not atomically commit a separate payment provider. Use an explicit idempotency or transaction protocol rather than equating a replicated command with universal exactly-once effects.

The queue lab illustrates application pressure only. Reset, explicitly set both arrival two and service three, predict draining from four pending items, then Play or Step. For a separate overload comparison Reset and explicitly set arrival four and service three, predict, then play. Interpret arrival as newly committed work and service as application work in normalized items per second. Control edits retain elapsed time and recompute from the initial four items. The model does not determine commitment, model entry terms, or show a real apply loop.