Raft Consensus

🟠 P1 — the understandable consensus algorithm; know conceptually, not implementation details

Problem #

Multiple nodes need to agree on a sequence of operations despite failures. This is the consensus problem.

Mechanism (Simplified) #

Raft decomposes consensus into three sub-problems:

1. Leader election: One node becomes leader via majority vote. Leader handles all writes.
2. Log replication: Leader appends entries to its log, replicates to followers. Entry committed when majority acknowledges.
3. Safety: Once committed, an entry is never lost or contradicted.

Term 1: Node A is leader
  → Client writes go to A
  → A replicates to B, C (majority = 2 of 3)
  → A commits and responds to client

A crashes → Term 2:
  → B and C hold election
  → B wins (has most recent log)
  → B becomes new leader

Instinct #

Know Raft conceptually, not algorithmically.

In interviews, you’re unlikely to implement Raft, but you should know:

(1) it’s leader-based,

(2) majority quorum for commits,

(3) leader election via term numbers,

(4) it’s what etcd, CockroachDB, and TiKV use.

If asked to compare with Paxos: “Raft is designed for understandability — same safety guarantees, more prescriptive on leader election and log management.”

References #

• In Search of an Understandable Consensus Algorithm — original paper
• raft.github.io — interactive visualisation
• The Secret Lives of Data: Raft — animated walkthrough

DDIA 2e Reference #

• Chapter 9: Consensus algorithms, total order broadcast