Raft is a consensus algorithm created to make distributed consensus easier to understand and implement. Developed by Diego Ongaro and John Ousterhout at Stanford University, Raft was introduced to simplify the complexity of earlier consensus approaches like Paxos.
- Raft was designed to be easier to understand and implement compared to Leslie Lamport’s Paxos, while still providing strong fault tolerance and consistency guarantees.
- It divides the consensus process into clear components such as leader election, log replication, and safety, making the algorithm simpler to reason about.
- Raft uses a single leader to manage log entries and coordinate communication, reducing system complexity and avoiding ambiguity.
Consensus
Consensus is the process through which multiple servers in a distributed system agree on the same value or sequence of operations. It helps the system behave consistently and reliably even when failures or communication delays occur.
- Consensus maintains consistent replicated data across servers, ensuring all nodes stay synchronized and correct.
- It also provides fault tolerance and predictable system behavior, allowing the system to continue operating despite crashes or network issues.
Properties of a Correct Consensus Algorithm
A reliable consensus algorithm must satisfy the following properties:
- Agreement: All correct (non-faulty) servers must agree on the same value.
- Validity: Any value that is decided must have been proposed by some server.
- Termination: Every correct server eventually makes a decision.
- Safety: Once a value has been decided, it can never be changed.
Raft strongly prioritizes safety, ensuring correctness even under extreme failure scenarios.
System Model and Assumptions
The Raft consensus algorithm is designed under a well-defined and realistic system model that reflects how most practical distributed systems behave. Understanding these assumptions is essential to understanding both the strengths and limitations of Raft.
Crash Fault Model
Raft operates under the crash fault model, which assumes that failures occur in predictable ways rather than arbitrarily. Specifically, Raft assumes that:
- Servers may crash and later restart at any time.
- Network messages may be delayed, lost, duplicated, or delivered out of order.
- Servers always behave correctly according to the protocol and do not act maliciously.
Raft does not support Byzantine failures, where servers behave maliciously or unpredictably. This simplification makes the algorithm easier to implement and suitable for controlled environments like data centers and cloud systems.
Replicated State Machine Model
Raft is built around the replicated state machine model, a common abstraction used in distributed systems.
In this model:
- Each server maintains a log of commands received from clients.
- Commands are applied in the same order on every server.
- If two servers have identical logs, they will reach the same internal state.
Raft’s primary responsibility is to ensure that these logs remain consistent across servers, even in the presence of failures.
Types of Systems Based on Server Configuration
To simplify understanding, consider a system with only one client interacting with servers.
Single-Server System
In a single-server system, the client interacts with only one server and no backup exists. Since there is only one authority handling all requests, consensus is trivial and no coordination mechanism is required. However, such systems are not fault-tolerant and fail completely if the server crashes.
Multi-Server System
In a multi-server system, the client interacts with a cluster of servers that replicate data for reliability. These systems can be classified into two categories:
- Symmetric systems: Any server can respond to client requests, and other servers later synchronize with the responding server. While this approach improves availability, it significantly complicates consistency and conflict resolution.
- Asymmetric systems: Only one server, known as the leader, is allowed to respond to client requests. All other servers synchronize their state with the leader. This model simplifies coordination and avoids conflicts.
Raft follows the asymmetric model, using a single elected leader to coordinate all updates.
Replicated State Machine in Raft
A system where all servers replicate and maintain the same shared state over time is called a replicated state machine. Raft ensures that:
- All state changes flow through a single leader.
- Updates are recorded in logs and logs are safely replicated to followers.
- All servers apply the same commands in the same order.
This model allows Raft-based systems to behave like a single reliable machine, even though they are composed of multiple independent servers.
Server Roles in Raft
Raft organizes each server into a well-defined role to clearly separate responsibilities and ensure predictable consensus behavior.
- Follower: Passive node that responds to leaders or candidates, replicates logs, and becomes a candidate if heartbeats stop.
- Candidate: Temporary role that initiates leader elections by requesting votes and becomes leader upon gaining a majority.
- Leader: Central coordinator that handles client requests, appends and replicates log entries, and maintains authority via heartbeats.
Remote Procedure Calls (RPCs)
Raft uses a minimal set of RPCs to coordinate consensus, which significantly simplifies the protocol and its implementation.
- RequestVote RPC: Used during leader elections; sent by candidates to request votes from other servers and includes term and log metadata.
- AppendEntries RPC: Used by the leader to replicate log entries to followers and also functions as a heartbeat when no entries are sent.
Leader Election Process
Leader election in Raft is triggered when followers stop receiving regular heartbeats from the current leader.
Election Steps
Election steps describe the sequence of actions a server follows to transition from follower to leader during a Raft election.
- A follower times out after not receiving a heartbeat.
- The server increments its term and transitions to the candidate state.
- The candidate votes for itself.
- RequestVote RPCs are sent to all other servers.
- Votes are collected until an outcome is reached.
Election Outcomes
Election outcomes define the possible results of a leader election based on vote counts and term comparisons.
- If a majority of votes is received, the candidate becomes the leader.
- If no majority is obtained, a split vote occurs and a new election begins.
- If a higher term is detected, the candidate steps down to follower.
Randomized Election Timeouts
Raft uses randomized election timeouts to reduce split votes, ensure rapid convergence, and maintain stable leadership.
Log Structure and Log Replication
Raft ensures consistency by organizing all state-changing operations into logs that are safely replicated across the cluster.
Log Entry Components
Each log entry contains the essential information required to preserve order and correctness across servers.
- Command received from the client.
- Log index identifying the entry’s position.
- Term number indicating when the entry was created.
Replication Workflow
This workflow describes how a client request is replicated and committed across the cluster.
- The client sends a request to the leader.
- The leader appends the request as a new entry in its local log.
- The leader sends AppendEntries RPCs to follower servers.
- Followers acknowledge successful replication of the entry.
- The entry is considered committed once it is stored on a majority of servers.
- The leader applies the entry and sends the response back to the client.
Followers apply the entry only after it is committed, ensuring consistency.
Handling Log Inconsistencies
Failures can cause logs to diverge. Raft resolves inconsistencies by:
- Treating the leader’s log as authoritative
- Overwriting conflicting follower entries
- Backtracking until a matching index and term are found
If two log entries share the same index and term, they are guaranteed to store the same command.
Safety Guarantees in Raft
Raft enforces safety using strict rules:
- Election Safety: At most one leader can be elected per term.
- Log Matching Property: If two logs contain an entry with the same index and term, they are identical up to that index.
- Leader Completeness: All committed entries from previous terms appear in the logs of future leaders.
- State Machine Safety: No server applies a different command at the same log index.
- Append-Only Leaders: Leaders only append entries; they never overwrite or delete their own logs.
Fault Tolerance and Recovery
Raft is designed to maintain correctness and availability even when servers fail and later recover.
Follower Crashes
This scenario describes how Raft handles failures of non-leader servers without disrupting the system.
- Missed log entries are recovered after the follower restarts.
- The follower synchronizes its log by receiving entries from the leader.
Leader Crashes
This scenario explains how Raft safely restores leadership when the current leader fails.
- Followers detect the absence of heartbeats from the leader.
- A new leader election is initiated automatically.
- A new leader is elected safely without violating consistency.
Raft can tolerate failures of up to (N − 1) / 2 servers in an N-node cluster.
Cluster Membership Changes
Changing the cluster configuration is dangerous if done incorrectly.
Raft uses joint consensus, a two-phase approach:
- Operate with both old and new configurations
- Transition fully to the new configuration
This ensures:
- Continuous availability
- Safe leadership transitions
- No loss of quorum
Advantages of Raft
Raft is designed to provide a practical, reliable, and easy-to-understand approach to achieving consensus in distributed systems.
- Easy to understand and teach due to its clear structure and well-defined roles.
- Uses a simple leader-based model that reduces coordination and conflict.
- Ensures strong correctness and safety guarantees for replicated state.
- Operates correctly despite failures of a minority of servers.
Limitations of Raft
Despite its strengths, Raft has certain constraints that affect its applicability.
- A single leader can become a performance bottleneck.
- No support for Byzantine fault tolerance.
- Optimized for a specific class of consensus problems.
- Performance depends heavily on the health and stability of the leader.
Raft Compared to Other Algorithms
- Paxos: More flexible but significantly harder to understand
- PBFT: Handles Byzantine failures but much more complex
- PoS / DPoS: Used in blockchain systems with different trust models
Raft strikes a balance between simplicity and correctness.