Raft
A consensus algorithm designed to be understandable. Uses leader election and log replication. Powers etcd (used by Kubernetes) and CockroachDB.
What is Raft?
In short
Raft is a consensus algorithm that keeps a cluster of servers in agreement on an identical, ordered log of operations even when some servers crash or messages are lost. It works by electing one leader that accepts all writes and replicates them to follower servers, and it was deliberately designed to be easier to understand than the older Paxos algorithm.
What Raft actually is
Raft solves the consensus problem: getting a group of independent servers to agree on the same sequence of values, so that the cluster behaves like one reliable machine even though individual servers fail. The agreed-upon sequence is a replicated log. Every server applies the same log entries in the same order, so they all end up in the same state.
The classic use is a replicated state machine. You feed the same commands, in the same order, to identical copies of a program running on several servers. As long as a majority of servers stay alive and connected, the cluster keeps serving requests and never returns conflicting answers.
Raft was published in 2014 by Diego Ongaro and John Ousterhout at Stanford. Their explicit goal was understandability. Paxos, the algorithm that came before it, is famously hard to reason about and implement correctly, so Raft breaks the problem into three pieces a normal engineer can hold in their head: leader election, log replication, and safety.
How it works under the hood
At any moment a Raft server is in one of three roles: leader, follower, or candidate. There is at most one leader, and it handles every client write. Time is divided into terms, which are just monotonically increasing numbers that act as a logical clock. Each term has at most one leader.
When a follower stops hearing heartbeats from the leader for a randomized timeout (often 150 to 300 milliseconds), it bumps the term number, becomes a candidate, and requests votes from the others. A server grants its vote to the first valid candidate it sees in that term. Whoever collects votes from a majority becomes the new leader. The randomized timeouts make it unlikely two candidates split the vote repeatedly.
Once elected, the leader appends each client command to its own log and sends AppendEntries messages to the followers. An entry is committed once a majority of servers have stored it. Only then does the leader apply it to its state machine and reply to the client. Because commit requires a majority, a five-node cluster keeps working with two nodes down, and a three-node cluster tolerates one failure.
Safety comes from a few rules: a candidate can only win if its log is at least as up to date as the majority that votes for it, and entries are never overwritten once committed. This guarantees the elected leader already holds every committed entry, so no acknowledged write is ever lost.
When to use it and the trade-offs
Reach for Raft when you need strong consistency and a single source of truth that survives machine failure: configuration stores, service discovery, distributed locks, leader election for other systems, and the metadata layer of databases. It gives you linearizable reads and writes, which means clients see one consistent timeline rather than stale or conflicting values.
The main cost is latency and throughput. Every committed write needs a network round trip to a majority, so a write is only as fast as your slowest majority member. Spreading a cluster across regions adds tens of milliseconds per write. Raft also requires an odd number of nodes for clean majorities, and it cannot make progress without one, so a network partition that isolates the minority side stops that side from accepting writes by design. That is the CAP trade-off: Raft chooses consistency over availability during a partition.
Raft is not a general scaling tool. Adding nodes improves fault tolerance and read capacity, but writes still funnel through one leader, so write throughput does not increase by adding members. Systems that need huge write volume shard the data across many independent Raft groups, each with its own leader.
A concrete real-world example
etcd is the clearest example. It is a distributed key-value store built directly on Raft, and it is the brain of every Kubernetes cluster. The Kubernetes API server stores all cluster state in etcd: which pods should run, secrets, config maps, and the desired state of every object. A typical production setup runs three or five etcd members so the control plane survives losing a node.
When you run kubectl apply, the request reaches the API server, which writes to the etcd Raft leader. The leader replicates that change to its followers, and once a majority confirm it, the write commits and Kubernetes acts on it. If the etcd leader crashes, the remaining members elect a new one within a second or two, and the cluster keeps operating without losing any committed state.
Where it is used in production
etcd
Distributed key-value store built on Raft; stores all Kubernetes cluster state and runs as a 3 or 5 node Raft group.
CockroachDB
Distributed SQL database that shards data into ranges, each replicated and kept consistent by its own Raft group.
HashiCorp Consul
Uses Raft for its server cluster to keep service discovery and configuration data consistent and to elect a leader.
TiKV
The distributed storage layer behind TiDB; uses one Raft group per data region to replicate writes across nodes.
Frequently asked questions
- What is the difference between Raft and Paxos?
- Both solve the same consensus problem and give the same guarantees. The difference is design clarity. Paxos is described in terms of abstract proposers and acceptors that are hard to map onto a working system. Raft splits the problem into leader election, log replication, and safety, and it uses a single strong leader, which makes it far easier to understand, implement, and debug. That is why most modern systems pick Raft.
- How many servers do I need to run Raft?
- You need a majority to commit anything, so odd numbers work best. Three nodes tolerate one failure, five nodes tolerate two. Going to four nodes gives no extra fault tolerance over three because you still need three votes for a majority. Most production clusters use three or five members.
- What happens to Raft during a network partition?
- The side that still has a majority elects or keeps a leader and continues accepting writes. The minority side cannot reach a majority, so it stops accepting writes and may serve only stale reads. Raft deliberately sacrifices availability on the minority side to guarantee it never returns inconsistent data. When the partition heals, the minority catches up from the leader.
- Does Raft make writes faster?
- No. Raft adds latency because every committed write must be acknowledged by a majority of servers over the network. It buys you fault tolerance and strong consistency, not speed. Adding more nodes does not raise write throughput either, since all writes go through one leader. Scaling writes means running many independent Raft groups over sharded data.
- Is Raft strongly consistent?
- Yes. Raft provides linearizability for writes and for reads that go through the leader, meaning every client observes a single agreed-upon order of operations. Once a write is acknowledged it is durable and will never be lost or reordered, even across leader changes and crashes.
Learn Raft hands-on
This page explains the idea. The full lesson lets you step through the ring as servers join and leave, read the implementation, and check yourself with a quiz. It is one of 760+ lessons in the System Design Masterclass, from your first API call to distributed consensus. Eleven Foundation lessons are free, no signup. Lifetime access is ₹499 in India or $7.99 worldwide, one payment, no subscription.
Related lessons
Lessons that touch on Raft as part of a larger topic.
Consensus Algorithms
Paxos, Raft, and ZAB, how distributed nodes agree on a single value despite failures
advanced · distributed systems core
Leader Election
How distributed nodes pick a leader without a central authority, bully algorithm, ring, and Raft elections
advanced · distributed systems core
Deterministic Scaffolding: The LLM Explains, It Does Not Arbitrate
Deterministic scaffolding keeps control flow in code and calls the model only to classify or draft. The model recommends; code checks state and arbitrates.
ml-intermediate · agents in production
See also
Related glossary terms you might want to look up next.
Paxos
A family of protocols for solving consensus in unreliable networks. Famously difficult to understand but mathematically proven correct.
Consensus
The process of getting multiple nodes in a distributed system to agree on a single value. The foundation of distributed databases and coordination services.
Leader Election
The process of choosing one node in a cluster to coordinate actions. If the leader fails, a new one is elected. Used by Kafka, ZooKeeper, and etcd.
CAP Theorem
In a distributed system, you can only guarantee two of three: Consistency, Availability, and Partition tolerance. You must choose your trade-off.
CQRS
Command Query Responsibility Segregation: using different models for reading and writing data. Reads and writes have different performance needs, so separate them.
Event Sourcing
Storing every state change as an immutable event instead of just the current state. You can rebuild any past state by replaying events.