We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Distributed Systems Core
A consensus algorithm designed to be understandable. Uses leader election and log replication. Powers etcd (used by Kubernetes) and CockroachDB.
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.
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.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Raft across a run of lessons, not one page. These 3 alone are about 125 minutes of step-by-step reading, 2 of them with code you run in the browser, all with a quiz.
Paxos, Raft, and ZAB, how distributed nodes agree on a single value despite failures.
What is quorum in system design? How read and write quorums work, why R + W > N, sloppy quorums, hinted handoff and quorum vs consensus, with a lab.
How distributed nodes pick a leader without a central authority, bully algorithm, ring, and Raft elections.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Consensus Algorithmspay once,
yours for life
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.
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.
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 clusters usually run an odd number of nodes, because an even count adds no extra fault tolerance, 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.
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.
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.
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.
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.
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.
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.
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.
Quorum in Distributed Systems
What is quorum in system design? How read and write quorums work, why R + W > N, sloppy quorums, hinted handoff and quorum vs consensus, with a lab.
Leader Election
How distributed nodes pick a leader without a central authority, bully algorithm, ring, and Raft elections
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.
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
When a network failure splits a distributed data store, each node must either refuse requests to stay consistent or keep answering with possibly stale data. It cannot guarantee both during the partition.
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.
This page explains the idea. The "Consensus Algorithms" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Consensus Algorithms lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Raft in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
