Raft Algorithm

What is Raft?

If you've read about Paxos, you know that distributed consensus is critical but notoriously difficult to wrap your head around. In 2013, researchers at Stanford created Raft with one primary goal in mind: understandability.

Raft does the exact same job as Paxos. It helps a cluster of servers agree on a sequence of events, ensuring that even if some servers crash, the system remains consistent and available. It breaks the problem down into simpler, more intuitive pieces.

The Core Concept: Follow the Leader

Think about a group project. If everyone tries to be in charge at the same time, it's chaos. Decisions take forever, and people get confused. The most efficient way to get things done is to elect a single team leader. The leader makes the decisions, writes them down, and tells everyone else what to do. If the leader gets sick (crashes), the group pauses, elects a new leader, and resumes work.

This is exactly how Raft works. It achieves consensus via strong leadership.

At any given time, every server in a Raft cluster is in one of three states:

1. Leader: The boss. Handles all client requests and replicates data to the others.
2. Follower: The workers. They passively receive instructions from the Leader.
3. Candidate: A Follower who realized the Leader is missing and wants to take over.

How Raft Works

Raft breaks consensus down into two main sub-problems: Leader Election and Log Replication.

1. Leader Election

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Leader election begins when a follower's randomized election timeout fires without receiving a heartbeat. That follower becomes a Candidate and sends RequestVote RPCs to all peers. A peer grants its vote if it has not already voted this term and the candidate's log is at least as up-to-date as its own. The candidate that receives votes from a majority of the cluster becomes the new Leader and immediately starts sending heartbeat messages to prevent another election from starting. Randomized timeouts (150-300ms) ensure two nodes rarely time out at the same instant, minimizing split-vote scenarios.

1 / 10.5×1×2×3×Playground

Raft leader election — randomized timeouts, vote requests, majority wins

When a cluster starts, all nodes are Followers. They all have a randomized countdown timer called an "election timeout" (usually between 150ms and 300ms).

• The first node whose timer runs out says, "I haven't heard from a leader! I'm becoming a Candidate!"
• It votes for itself and asks the other nodes for their votes.
• If it gets a majority of votes, it becomes the new Leader.
• The Leader then constantly sends "heartbeat" messages to the Followers (essentially saying, "I'm still alive, reset your timers!").

If the Leader crashes, the heartbeats stop. A Follower's timer runs out, and a new election begins. The randomized timers ensure that two nodes don't constantly tie in elections.

2. Log Replication

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

All client writes go to the Leader. The Leader appends the entry to its log and broadcasts AppendEntries RPCs to all Followers. Once a majority of nodes (including the Leader) have durably written the entry, the Leader marks it committed, applies it to its state machine, and notifies Followers to do the same. The client receives confirmation only after this quorum write. If the Leader crashes mid-replication, the new Leader will have all committed entries (guaranteed by Raft's election safety property) and will re-send any uncommitted entries to Followers.

1 / 10.5×1×2×3×Playground

Raft log replication — client write, AppendEntries to followers, quorum commit

Once a Leader is in charge, how does it handle data?

1. A client sends a request (e.g., "Set X = 5") to the Leader.
2. The Leader writes this command to its own log, but doesn't apply it yet.
3. The Leader sends this log entry to all Followers.
4. Once a majority of Followers acknowledge they've written it to their logs, the Leader officially "commits" the change and applies it to its state machine.
5. The Leader then tells the Followers, "It's committed! You can apply it too."

This ensures that once a decision is made by a majority, it is permanently safe, even if nodes crash.

Real-World Examples

Raft's simplicity has made it the go-to consensus algorithm for modern distributed systems.

• etcd: The key-value store that acts as the brain of Kubernetes. It stores all cluster data and configuration. It uses Raft to ensure that even if a master node dies, the cluster state remains consistent.
• Consul: HashiCorp's service mesh and service discovery tool relies on Raft to manage its internal state.
• CockroachDB: A distributed SQL database that uses Raft to replicate ranges of data across multiple geographic locations, providing high availability and strong consistency.

Summary

• Raft is a distributed consensus algorithm designed specifically to be easier to understand and implement than Paxos.
• It operates strictly on a Leader-Follower model. All changes must go through the Leader.
• Consensus is achieved through two main mechanisms: Leader Election (using randomized timeouts) and Log Replication (requiring a majority quorum to commit data).
• It powers massive modern infrastructure tools like etcd (Kubernetes), Consul, and distributed databases.