Raft Advanced

Beyond the visualizer

Topic 6 covers election and log replication. Production Raft (etcd, Consul, TiKV) adds mechanisms the interactive tutorial skips.

Log compaction (snapshots)

Unbounded logs exhaust disk. The leader snapshots applied state, truncates the prefix, and ships InstallSnapshot RPCs to lagging followers.

Interview points:

• Snapshot includes last included index/term — follower rejects stale snapshots
• Compaction must not discard uncommitted entries followers still need
• Trade-off: snapshot frequency vs recovery time vs disk use

Joint consensus (membership changes)

Naively removing/adding nodes can create two majorities with overlapping misconfiguration. Raft uses joint consensus:

1. Enter C_old,new — quorum = majority of (old ∪ new)
2. Replicate config change entry
3. Exit to C_new — quorum = majority of new only

Never change more than one node at a time in ops practice; the algorithm allows arbitrary transitions but ops play it safe.

Pre-vote

A partitioned node with a high term can disrupt a healthy cluster when it rejoins — followers reject the real leader, trigger needless elections.

Pre-vote round: candidate asks "would you vote for me?" without incrementing term. If no quorum would vote, stay follower. etcd and modern implementations include this.

Read-only queries

Linearizable reads from leader without log entry — ReadIndex / Lease read (leader assumes lease valid if no election). Follower reads sacrifice linearizability unless FollowerRead with monotonic reads + validation (product-specific).

Failure scenarios to rehearse

1. Leader partitions from majority — writes stall, new leader elected
2. Old leader rejoins — steps down, uncommitted entries rolled back
3. One follower slow — leader revokes, catches up via snapshot
4. 3→5 expansion — joint consensus phase before trusting new quorum

Link to Topic 6

Start with the visualizer; this subtopic is what infra loops ask after you pass the whiteboard basics.