How Raft replicates a log entry and decides it is safe to commit

A client sends SET x = 42 to a Raft cluster. The leader appends it to its log. But the leader alone cannot commit that write — it needs confirmation from enough followers that they have it too. If the leader crashes right after appending but before any follower responds, what happens to the write?

The log and AppendEntries

The Raft leader maintains an ordered log of entries. Each entry is a tuple: (term, index, command). When a client sends a write:

1. Leader appends the entry to its own log and fsyncs to disk.
2. Leader sends AppendEntries RPC to every follower, carrying: the new entry, plus prevIndex and prevTerm — the index and term of the entry immediately before the new one.
3. Each follower checks: does my log have an entry at prevIndex with prevTerm? If yes, append and fsync. If no, reject with a mismatch reply.
4. Once the leader hears acknowledgement from a majority (including itself), it marks the entry committed.
5. The leader piggybacks its commit index on the next heartbeat. Followers apply entries up to that index to their state machines.

The consistency check: Log Matching

The prevIndex/prevTerm check is not bureaucracy — it is the mechanism that keeps every follower’s log identical to the leader’s. If a follower’s log diverges (because a previous leader wrote different entries before crashing), the mismatch reply tells the leader to back up and retry with an earlier prevIndex. The leader keeps decrementing until it finds the last point of agreement, then overwrites the follower’s divergent tail with its own.

This converges to identical logs because: any entry that was committed in a prior term was stored by a majority of nodes. The new leader’s log (elected by majority) overlaps with that prior majority, so the new leader has those committed entries. Uncommitted entries on the old leader’s disk get overwritten — they were never acknowledged to any client, so no data is lost.

The replicated state machine pattern

Raft does not care what commands mean. Your application defines the state machine — a key-value map, a config tree, a relation — and the commands that mutate it. Raft guarantees: every node applies every committed entry in the same order. Since the commands are deterministic, every state machine ends up in the same state. This is the replicated state machine pattern: ordered replicated log + deterministic state machine = consistent distributed service.

Important consequences:

• Do not use NOW(), random(), or external API calls inside command handlers — these break determinism across replicas.
• The state machine is application-specific; Raft is agnostic to it.
• Reads for linearizability must go through the leader (covered in a later lesson); follower reads may return stale data.