Definition
- Consensus -- getting unreliable machines to agree on a value or sequence of values despite crashes and delays.
- Leader election -- time divided into terms; a candidate requests votes and becomes leader with a majority.
- Log replication -- all commands go to the leader, which appends and replicates; committed when a majority store it.
- Safety -- a node only votes for a candidate whose log is at least as up-to-date; committed entries are never lost.
- Quorum -- strict majority; 5-node cluster tolerates 2 failures, 3-node tolerates 1.
- In practice -- etcd (K8s state), Consul (discovery), Kafka KRaft (metadata).
Five branch managers at National Bank of India must keep an identical master ledger. Raft is the rulebook. They elect one head manager for the day (majority vote). Every new entry goes to the head manager, who sends copies to the others; the entry is official only once more than half have recorded it. Once official, it can never be erased, even if a different manager takes over tomorrow.
Understanding the Concepts
What problem does Raft solve?
Consensus: getting a set of unreliable machines to agree on a sequence of values despite crashes and delays. It is the foundation for cluster membership, configuration, and leader locks.
How does leader election work?
Raft divides time into terms. Every node is follower, candidate, or leader. If a follower hears no heartbeat, it becomes a candidate and requests votes.
// Conceptual leader election
int votes = 1; // vote for self
for (Node peer : peers) {
if (peer.requestVote(term, lastLogIndex, lastLogTerm)) votes++;
}
boolean becomesLeader = votes > clusterSize / 2; // strict majority
// Randomized election timeouts make split votes rare
How does log replication work?
All client commands go to the leader. The leader appends and replicates. Committed when a majority store it.
// Conceptual log replication
log.append(new Entry(term, command));
int stored = 1; // leader itself
for (Node follower : peers) {
if (follower.appendEntries(term, entry)) stored++;
}
if (stored > clusterSize / 2) {
commitIndex = entry.index;
applyToStateMachine(entry); // all nodes apply in same order
}
How does safety work?
- A node votes for a candidate ONLY if the candidate's log is at least as up-to-date.
- A node missing committed entries can never become leader.
- A new leader never deletes committed entries.
- Result: once committed, every future leader has the entry.
Why odd cluster sizes?
| Cluster Size | Majority | Tolerates |
|---|---|---|
| 3 | 2 | 1 failure |
| 5 | 3 | 2 failures |
| 7 | 4 | 3 failures |
Where is Raft used in practice?
| System | What Raft manages |
|---|---|
| etcd | Kubernetes cluster state (pods, services, config) |
| Consul | Service catalog + key-value store for discovery |
| Kafka KRaft | Topic, partition, and leadership metadata (replacing ZooKeeper) |
What is the boundary between Raft and the data plane?
// Raft is for the SMALL, CRITICAL coordination state:
// - Which node is primary?
// - What is the cluster configuration?
// - Distributed locks
// NOT for the high-throughput data plane:
// - Millions of transactions per second
// - Requiring majority ACK on every write would not scale
// The data store that Raft COORDINATES handles the bulk throughput
What are common mistakes?
// WRONG: using Raft for every write in a high-throughput system
// Majority ACK on every transaction → too slow for millions of TPS
// CORRECT: Raft for metadata/coordination; data store for throughput
// etcd agrees on who is primary; the primary handles the transactions
What should a senior engineer know?
- Raft is for the metadata and coordination plane, not the data plane.
- A bank would use Raft to agree on which node is the primary or on configuration, while actual transactions are handled by the data store Raft coordinates.
- Understanding this boundary separates surface knowledge from knowing where Raft belongs.
- Raft clusters are sized at odd numbers to maximize fault tolerance per node.
Visual Overview
Raft Leader Election
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Node-A │ │ Node-B │ │ Node-C │
│(follower)│ │(candidate)│ │(follower)│
└──────────┘ └────┬─────┘ └──────────┘
│ RequestVote
┌─────────────┼─────────────┐
▼ ▼ ▼
vote YES (self) vote YES
│
2/3 majority → LEADER
Raft Log Replication
┌──────────┐ AppendEntries ┌──────────┐
│ Leader │ ──────────────► │Follower-A│ stored ✓
│ │ ──────────────► │Follower-B│ stored ✓
└──────────┘ └──────────┘
2/3 majority → COMMITTED (applied to state machine)
Where Raft Fits
┌────────────────────────────┐
│ Coordination Plane (Raft) │ small, critical, strongly consistent
│ etcd, Consul, KRaft │
├────────────────────────────┤
│ Data Plane │ high-throughput, scalable replication
│ PostgreSQL, Kafka, Redis │
└────────────────────────────┘
Key Takeaway
Raft is a consensus algorithm that lets a cluster of nodes agree on one ordered log of commands despite crashes and delays. Leader election divides time into terms and elects a leader by majority vote. Log replication sends all commands through the leader, which replicates to followers and commits when a majority store the entry. Safety rules ensure committed entries are never lost, even across leader changes.
Raft powers the coordination planes of major systems: etcd stores Kubernetes cluster state, Consul keeps its service catalog consistent, and Kafka KRaft manages topic and partition metadata. The key insight is that Raft is for the small, critical, strongly-consistent state, not the high-throughput data plane, because requiring majority acknowledgement on every write would not scale to millions of transactions.
At National Bank of India, Pankaj would use a Raft-backed store like etcd to agree on which data centre is the current primary for transfers or to hold a distributed lock for a settlement job, while the actual transaction throughput is handled by the data store that Raft coordinates.
Remember one sentence: Raft makes a cluster agree on one ordered log via leader election, majority-quorum commits, and safety rules that preserve committed entries, and it belongs in the coordination plane (etcd, Consul, KRaft), not the high-throughput data plane.
---