A cruicual aspect of distributed systems is to have a clear consensus on who is the current leader. Consensus algorithms help us in determining a leader and provide us with the constitution for what happens when the leader inevitably goes down. Enter Raft, the algorithm that promises to make consensus more understandable. While its popular peer Paxos has an air of mystique, Raft is the algorithm that rolls up its sleeves and says, “Let’s make this easy to follow.”

Let’s dive into Raft, piece by piece, and understand how it works.

What is Raft?

Raft is a consensus algorithm designed to manage a replicated log across multiple servers in a distributed system. The goal is simple: maintain consistency across all nodes, even when some nodes fail or communicate poorly.

Raft breaks down the process of consensus into manageable tasks. These are:

  • Leader election
  • Log replication
  • Safety

So, while it doesn’t guarantee zero downtime in your production environment (we can’t all be that lucky), it ensures that your distributed system won’t descend into chaos.

Roles in Raft: The Triad

In Raft, every server can be in one of three roles:

  1. Leader: The head honcho. It’s responsible for handling all client interactions and log replication. There’s always just one leader in a cluster.
  2. Followers: These nodes are the chill ones. They receive logs from the leader and apply them without fuss.
  3. Candidates: When a follower decides that the leader’s gone AWOL, it becomes a candidate and runs for office, initiating a new election.

The system starts with followers. If they haven’t heard from a leader for a while (a timeout), they become candidates and start an election. The goal is for one node to become the leader, and Raft ensures that only one can win, avoiding the political chaos we often see in real-world elections.

Leader Election: No Campaigning, Just Votes

Election in Raft is beautifully simple:

  1. Timeout: If a follower hasn’t heard from a leader in a certain period, it becomes a candidate.
  2. Vote Requests: The candidate sends requests to all other nodes, asking for their vote.
  3. Majority Rules: If the candidate receives votes from the majority of nodes, it becomes the leader. If not, it goes back to waiting.

This majority voting system is crucial. It ensures that only one leader can exist at any time. If two candidates get half the votes, they go back to square one, and the election process repeats.

Log Replication: Keeping Everyone on the Same Page

Once a leader is elected, it’s responsible for managing the replicated log — a list of commands (or entries) that all servers apply in the same order. The leader appends new entries to its own log and then sends these entries to its followers.

Here’s how it works:

  1. Client Requests: The client sends a request to the leader to perform an operation, like “Add item to shopping cart” or “Delete embarrassing tweet.”
  2. Append Entries: The leader adds the request to its log and then sends it to all the followers in AppendEntries RPCs.
  3. Majority Acknowledgment: The leader waits until a majority of followers have written the log entry. This is where the magic of consistency happens: even if some followers are lagging behind, as long as a majority agrees, the system stays consistent.
  4. Commit: Once a majority of nodes confirm the log entry, the leader marks it as committed, and the client is notified of success.

This ensures that, even if the leader crashes, another node can step in, take over, and apply the same sequence of operations. The cluster remains consistent, no matter what life throws at it.

Safety: The Non-Negotiable

Raft places a heavy emphasis on safety, ensuring that once a log entry is committed, it’s never lost. This is where Raft gets a little more strict than your typical casual Friday at work.

Term Numbers

Raft divides time into terms, and each term is associated with a leader. If a leader fails, a new term begins with a fresh election. Terms are important because they act like timestamps for decisions, preventing outdated nodes from making incorrect decisions.

Election Safety

Raft ensures that only one leader is elected in a term. If there’s a split vote, nodes just go back to the election phase. Only when a candidate receives a majority does it ascend to the role of leader.

Log Matching

Raft guarantees that if two logs match at a given index and term, they match for all preceding entries. This is what prevents data from going out of sync.

Leader Append-Only Rule

Leaders never overwrite or delete entries in their logs. They only append, ensuring that log consistency is maintained even if there’s a network partition or delay.

This deserves a more in depth discussion. Stay tuned for a future post.

Handling Failures: The Inevitable

Since Raft is built for distributed systems, it’s designed to handle all kinds of failures:

  • Leader Failure: When the leader goes down, followers step up to become candidates, and a new leader is elected.
  • Follower Failure: If a follower crashes or gets cut off from the network, it’ll simply catch up when it comes back online. The leader will send the missing log entries once communication is restored.

Raft assumes that network partitions are real and frequent. So, instead of trying to prevent them, it handles them gracefully.

How does the client connect with the leader

Initial Request

The client sends its request (e.g., “add item to cart”) to any node in the cluster. This could be the leader, a follower, or even a candidate. The client doesn’t need to know the current leader in advance.

Follower Response

If the client sends the request to a follower or candidate, that node will respond with a special message like, “I’m not the leader, but here’s who I think the leader is.” The follower will either point directly to the leader or indicate that an election is ongoing.

Redirect to Leader

Upon receiving the follower’s response, the client redirects the request to the leader (or retries if the leader is still unknown, in case of an election). This process repeats until the client reaches the current leader.

Leader Lease

Once the client knows who the leader is, it can keep sending requests directly to that leader until a timeout or an error occurs (e.g., the leader crashes or steps down). If that happens, the process repeats, and the client once again starts by contacting any node to find the new leader.

This design allows the system to be fault-tolerant without requiring the client to always have an up-to-date list of who the leader is. Instead, the system handles the redirection seamlessly.

Raft vs. Paxos: The Simplicity Showdown

You might be wondering: “Why Raft? Why not Paxos?” Paxos is indeed the older, more battle-hardened cousin of Raft. But while Paxos is robust, it’s notoriously difficult to understand and implement. Raft, on the other hand, is designed with clarity in mind. It’s not about being better but being easier to reason about.

Raft splits the consensus problem into smaller, digestible chunks: leader election, log replication, and safety. By making the algorithm more modular, Raft becomes more approachable without sacrificing the key properties of consensus.

No Drama, Just Consensus

Raft is one of those algorithms that keeps your distributed system sane, even when the world (or your network) is falling apart. Its focus on clarity and simplicity makes it a fantastic choice for anyone building a distributed system, ensuring that all nodes agree on what’s what, with minimal confusion.