§15.1–15.3 Raft Consensus, Snapshots, and 100K IOPS

1. Overview

Raft turns a cluster into one ordered state machine: the leader assigns every client command a log index, replicates that entry to a majority, and only then applies it. The hard parts are keeping elections safe, repairing divergent logs, bounding replay time with snapshots, and making the hot path batch enough work to reach high IOPS.

2. Key Data Structures

Raft is built from three wire/data records: log entries carry commands, AppendEntries both heartbeats and replicates data, and RequestVote enforces the up-to-date election rule.

3. Core Mechanism

§15.1 — Leader Election

A node is normally a follower; if it stops receiving valid leader heartbeats before its randomized election timeout, it becomes a candidate and asks the cluster for votes.

The election RPC is deliberately small: the candidate includes its term and last log position, and each voter grants at most one vote per term.

Log Replication and Commit

Background: a client write must survive leader failure without letting two different commands occupy the same committed log slot.

Plan: the leader appends locally, sends AppendEntries with the previous slot proof, waits for a majority, advances commitIndex, applies the command, and replies to the client.

Example: assume the leader has committed through index 41 and receives set x=7. It appends entry 42 term 9, followers accept only if their index 41 term matches, and the leader commits 42 after any two followers in a five-node cluster acknowledge it.

Election Restriction

A voter grants a vote only when the candidate log is at least as up-to-date as its own log; term wins first, then index breaks ties. This prevents a leader that lacks a committed entry from being elected.

§15.2 — Snapshots, Freeze, and Replay

Background: an always-growing log makes restart and follower catch-up proportional to the lifetime write volume, so production Raft periodically snapshots the state machine and truncates old entries.

Plan: freeze the applied boundary, serialize state, persist snapshot metadata, truncate covered log entries, then unfreeze writes and send InstallSnapshot to followers that are too far behind.

Crash recovery restores the latest snapshot first, then replays only the suffix after lastIncludedIndex, which turns replay from millions of entries into the recent tail.

Single-server membership changes keep quorum math simple: add one node, catch it up, promote it, and only then remove another node if needed.

InstallSnapshot is chunked so a leader can transfer a large state image without requiring one enormous RPC buffer.

§15.3 — Performance Optimizations

Without pipelining, a leader pays one network RTT per AppendEntries batch and leaves the follower and transport idle between acknowledgements.

With pipelining, the leader tracks nextIndex and matchIndex per follower and sends later batches before earlier ACKs return.

Batching accumulates several client commands into one log append and one AppendEntries round, amortizing serialization, TCP packetization, and fsync overhead.

4. Minimal C Demo

The first demo models the core AppendEntries consistency check: a follower accepts a leader batch only when the previous index and term match, then deletes any conflicting suffix.

The second demo shows why batching and pipelining move throughput: fewer quorum rounds and overlapping waits reduce time per command.

5. Kernel Source Pointers

Raft is not a Linux kernel subsystem, so the useful source pointers are production consensus libraries that mirror the mechanisms above.

6. Interview Prep