Raft Consensus

Overview

Raft is a consensus algorithm that lets a cluster agree on an ordered log of commands. It decomposes the problem into leader election, log replication and safety, which makes it far easier to implement correctly than classic Paxos. Systems such as etcd and Consul use it for their source of truth.

How it works

A client sends a command to the leader. The leader appends it, replicates it, and replies once a majority has persisted it.

Client -> Leader: set x=1
Leader  -> F1, F2: AppendEntries(term=3, idx=7, cmd)
F1 ack, F2 ack   (2 of 3 = majority)
Leader: commitIndex=7, apply, reply OK
Followers learn commitIndex on next heartbeat

Elections use randomized timeouts, for example 150 to 300 ms, so one candidate usually wins. A voter grants its vote only if the candidate log is at least as up to date as its own. The leader never overwrites its log and followers truncate conflicting suffixes to match it.

Pitfalls

• Reading from a follower or a stale leader can return old data. Use read index or leader leases for linearizable reads.
• Election timeouts shorter than network jitter or disk fsync pauses cause constant re-elections.
• Even-sized clusters add cost without tolerating more failures; 4 nodes still tolerate only 1.
• Membership changes must go through joint consensus or single-server steps, never by editing configs on all nodes at once.
• Skipping fsync before acknowledging breaks the safety proof.

Key takeaways

• Raft gives linearizable replicated state with a single leader per term.
• Commit means stored on a majority, so size clusters at 3 or 5.
• Keep consensus groups small and use them for control data, not bulk traffic.
• Tune timeouts against real disk and network latency.