Login
C Tutorials C++ Tutorials Java Tutorials Python Tutorials JavaScript Tutorials TypeScript Tutorials C# Tutorials Go Tutorials Rust Tutorials PHP Tutorials Kotlin Tutorials Swift Tutorials
HTML Tutorials CSS Tutorials Frontend Development Backend Development React Tutorials Next.js Tutorials Node.js Tutorials Django Tutorials Mobile App Development
Beginner Tutorials Advanced Guides Coding Roadmaps Interview Preparation DSA Tutorials Projects & Examples Cheat Sheets
About Us Contact Privacy Policy Terms & Conditions Disclaimer Sitemap

Raft Consensus: Understandable Distributed State Machine Replication

In distributed systems, multiple independent server nodes must agree on a shared state—such as configuration parameters, lock ownership, or database commit sequences—even in the presence of network partitions, packet loss, and node crashes.

Historically, Paxos was the primary consensus algorithm, but its conceptual complexity made robust production implementations notoriously difficult. Introduced by Diego Ongaro and John Ousterhout in 2014, the **Raft Consensus Algorithm** was designed with understandability as a core tenet, decomposing consensus into three formal sub-problems: Leader Election, Log Replication, and Safety.

Node Roles and Logical Terms

At any given instant, every node in a Raft cluster exists in one of three distinct roles:

  • Follower: Purely passive role. Followers respond to incoming Remote Procedure Calls (RPCs) from leaders and candidates, initiating no requests independently.
  • Candidate: Active transition state. When a follower suspects the leader has failed, it transitions into a candidate to solicit election votes.
  • Leader: The authoritative coordinator. The leader handles all client interaction, receives new log entries, and commands followers to replicate and commit records.

Time in Raft is divided into arbitrary numbered units called **Terms** (acting as logical clocks). Terms increase monotonically. Each term begins with an election; if a candidate wins, it serves as leader for the duration of that term.

Leader Election & Heartbeat Timing

1. Election Timeouts

Followers expect periodic empty log RPCs (heartbeats) from the current leader. If a follower receives no heartbeat within a randomized window (typically between 150ms and 300ms), its election timer expires.

2. The Election Vote Process

  1. The node increments its current term counter and transitions to the Candidate state.
  2. It votes for itself and broadcasts a `RequestVote` RPC in parallel to all other cluster members.
  3. If the candidate secures a majority vote (e.g., 3 out of 5 nodes), it transitions to Leader and immediately broadcasts heartbeats to suppress other potential elections.
  4. If another node claims leadership with an equal or higher term, the candidate reverts to Follower.
  5. If a split vote occurs (no node secures a majority), the randomized election timeout ensures nodes retry at staggered times, breaking the deadlock quickly.

Log Replication & Quorum Commitment

Once elected, the leader acts as the single entry point for all writes:

  1. Client submits a command to the leader.
  2. Leader appends the command to its local log as an uncommitted entry.
  3. Leader issues `AppendEntries` RPCs to all followers to replicate the entry.
  4. Once a majority of followers acknowledge writing the entry to persistent storage, the leader applies the entry to its local state machine (Commit).
  5. The leader returns the execution result to the client and informs followers of the updated `commitIndex` in subsequent heartbeats, prompting followers to apply the entry locally.

Core Safety Invariants

  • Election Safety: At most one leader can be elected per term.
  • Leader Append-Only: A leader never overwrites or truncates its own log entries; it only appends new records.
  • Log Matching Property: If two logs contain an entry with the same index and term, they are guaranteed to be identical across all preceding entries up to that index.
  • Leader Completeness: If a log entry is committed in a given term, that entry will be present in the logs of the leaders for all higher-numbered terms (enforced by rejecting votes for candidates whose logs are less up-to-date).

Real-World Infrastructure Implementations

  1. etcd (Kubernetes Core): Uses Raft to maintain a consistent distributed key-value store powering cluster state and service discovery for Kubernetes.
  2. HashiCorp Consul: Employs Raft for control plane consensus, service mesh configurations, and distributed locking.
  3. CockroachDB & TiDB: Splits distributed SQL relational tables into key ranges, managing consensus and replication within each partition range using independent Raft groups (Multi-Raft).
  4. Apache Kafka (KRaft Mode): Replaced Apache ZooKeeper with an internal Raft consensus engine to manage partition metadata and controller quorum.