Diagrams

Complete visual guide to elections, replication, and failure handling.

Each diagram is designed to teach the decision point that matters: who has quorum, what is committed, and which node must step down.

Leader Election Flow

One follower times out first, starts a new term, requests votes, and becomes leader only after majority approval.

1

Heartbeat missing

A follower stops hearing from the leader before its randomized timeout expires.

→
2

Candidate

The node increments the term, votes for itself, and starts an election.

→
3

Vote check

Peers check term and log freshness before voting.

→
4

Quorum

Majority votes make the candidate leader. No majority means retry later.

Before election

A followerB followerC follower

During election

A candidateB voterC voter

After quorum

A leaderB followerC follower

Replication And Commit Flow

Replication creates copies. Commitment requires majority acknowledgment and is the safety boundary.

Leader path
1. Client sends write2. Leader appends entry3. Leader sends AppendEntries
Follower path
4. Followers check prevLogIndex / prevLogTerm5. Matching followers append and ACK6. Majority ACK means commit
Important: replicated is not the same as committed. The leader can respond safely only after quorum is reached.

Network Partition And Recovery

Raft chooses safety over unsafe availability when quorum is not reachable.

Minority partition

The old leader may still believe it is leader, but it cannot commit without quorum.

No safe commits

Majority partition

This side can elect a leader in a higher term and continue committing writes.

Writes continue

After recovery

The old leader sees the higher term, steps down, and uncommitted divergent entries are repaired.

Partition Scenarios

What actually happens when the network gets weird.

Progress depends on a majority being available. Safety does not depend on timing, but availability does.

Leader isolated in minority partition

The old leader cannot commit. The majority side can elect a new leader. Minority-only entries remain uncommitted and may be rolled back.

Follower isolated

The cluster remains available if the remaining nodes still form quorum. The isolated follower catches up later.

Delayed heartbeats

Packet loss or stalls can cause unnecessary elections and latency spikes even without a hard partition.

Asymmetric partition

Raft converges because terms and quorum depend on successful round trips, not one-way reachability.

No side has quorum

No leader can safely commit. Progress stops until quorum returns.

Figure-8 Raft Problem

The famous Figure-8 safety scenario

Figure-8 examples show why an older-term entry replicated to many nodes is not automatically committed. The current-term commit rule plus election restriction protects committed history across repeated leadership changes.

S1S2S3S4S5
Entries from old terms may spread widely, but only quorum-safe commitment protects history.