# Raft > Raft is a consensus algorithm that keeps a replicated log consistent across servers despite crashes and network partitions. In system design, it helps explain how a database, message log, or control plane can acknowledge writes and safely replace a failed leader without losing committed state. Source: https://sysround.com/concepts/raft Updated: 2026-11-05 ## How raft works A Raft group runs a replicated state machine: each server applies the same committed commands in the same order. One server is the leader; the others are followers. For example, three replicas might maintain an ordered log of key-value updates, with all writes routed to the leader. Leader election uses numbered terms. A follower that stops hearing heartbeats waits for a randomized election timeout, becomes a candidate, increments its term, and requests votes. Each server votes at most once per term and only for a candidate whose log is at least as up to date as its own, comparing the last entry's term first, then its index. A majority elects the leader. The leader appends a command to its log and sends AppendEntries requests to followers. Servers persist log entries before acknowledging replication, and persist their current term and vote before responding when those values change. In a three-server group, the leader needs durable replication on itself and at least one follower to form a majority. A leader can advance the commit position based on majority replication only for an entry from its current term; committing that entry also commits preceding entries. Servers apply committed entries in order, and the leader returns the command's result after applying it. This current-term rule and the voting restrictions preserve committed entries across elections. After a failure, an eligible candidate with majority support becomes leader. AppendEntries checks the preceding log index and term, allowing the leader to replace conflicting, uncommitted follower entries. A disconnected old leader may still believe it is in charge, but it cannot commit new writes without a majority; observing a higher term makes it step down. Reads need an explicit consistency policy: reading from any replica can return stale data. For a linearizable read, a leader can use a quorum-confirmed ReadIndex path after committing an entry in its term, then wait until its state machine has applied through the read index. Snapshots compact old log entries, and membership changes require a safe reconfiguration protocol rather than simply editing the server list. ## Worked example: A committed write survives a leader failure A key-value shard has three replicas: A, B, and C. A leads term 7 and receives request r42 to set inventory to 19. A persists log entry 101 and replicates it durably to B; two of three replicas form a majority. Because entry 101 belongs to term 7, A commits and applies it, but crashes before replying. C lacks entry 101 and cannot win B's vote with its older log. B can win term 8 with C's vote, replicate the missing entry, and commit a term-8 no-op before serving quorum-confirmed reads. The client retries r42; replicated request deduplication returns the stored result rather than executing a non-idempotent command twice. ## Trade-offs - **Consistency costs availability during partitions.** Only a connected majority can elect a leader and commit writes, so a minority partition must reject or defer them. - **Durable replication adds write latency.** Writes wait for persistent storage and enough replica responses to form a majority, making replica placement important, especially across regions. - **One leader limits each group's write capacity.** Batching and pipelining help, but scaling writes usually requires partitioning data across multiple Raft groups. - **Failover interrupts progress.** Election timeouts trade faster recovery against unnecessary elections caused by network delays, storage stalls, or process pauses. - **Operational correctness extends beyond election.** Snapshots, lagging-replica recovery, disk durability, and safe membership changes require careful implementation and testing. - **The fault model is limited.** Raft handles crash and communication failures, not malicious replicas, and it does not make external side effects exactly once. ## When to use it in a system design interview - A replicated storage design must preserve acknowledged writes when its leader fails. - A control plane needs one authoritative sequence of ownership, configuration, or failover decisions. - The interviewer asks what happens when a network partition leaves two servers claiming leadership. - The design needs linearizable state and can stop writes when a majority is unavailable. - You are designing a replicated message log or queue and must define exactly when an append is durable. ## How to bring it up in the interview - Start with the invariant: once a command is committed, future leaders must preserve it. Then explain majority replication, election restrictions, and terms as the mechanisms that protect it. - Draw a three-replica group and walk through a 2–1 partition. Explain that the two-server side can progress, while the isolated server cannot commit writes even if it still thinks it is leader. - Define the acknowledgment boundary precisely: durable majority replication, commitment, and state-machine application. Expect follow-ups about a leader crashing before replying and why retries still need request deduplication. - Separate log safety from read safety and external authority. Interviewers may ask how you prevent stale leader reads or stop an old controller from acting on another system; discuss quorum-confirmed reads and fencing tokens respectively. - State the scope: one Raft group orders one log, not every operation across the system. Explain partitioning for throughput, and prefer an established implementation over proposing to build consensus from scratch. ## Common mistakes - Calling Raft just a leader-election algorithm and omitting log replication, commitment, and state-machine application. - Saying any entry stored on a majority can immediately be committed, without the current-term restriction. - Assuming the candidate with the highest term automatically wins, regardless of majority votes and log freshness. - Treating every read from the leader as linearizable even when that leader has been isolated from the majority. - Claiming Raft prevents duplicate payments, fences external workers automatically, or provides atomic transactions across independent Raft groups. ## Interview questions where it comes up - [Design a distributed message log like Kafka](https://sysround.com/questions/design-kafka): Raft provides a concrete way to explain durable append acknowledgments, committed ordering, and safe leader replacement for each replicated partition. - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): A Raft-based design makes the choice of majority-backed writes and linearizable state explicit, including its availability cost during partitions. - [Design a distributed message queue like RabbitMQ](https://sysround.com/questions/design-message-queue): Replicating enqueue, lease, and acknowledgment state through Raft explains how queue state survives replica failover without promising exactly-once consumer side effects. - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Raft can maintain authoritative ownership and failover decisions, while fencing prevents stale controllers from acting on those decisions externally. ## FAQ ### How does Raft leader election work? After a randomized timeout without leader contact, a follower becomes a candidate, advances its term, and requests votes. It needs a majority, and voters reject candidates with less up-to-date logs. Split votes cause another election after new timeouts; eventual progress requires a sufficiently stable network and a reachable majority. ### What is the difference between Raft and Paxos? Both solve consensus under crash failures, but Raft organizes the replicated-log protocol around an explicit leader, terms, and constrained elections. Paxos describes consensus for individual decisions, while Multi-Paxos extends it to a sequence of decisions, typically using a stable leader. In an interview, compare the actual implementations and failure behavior rather than claiming one is inherently faster. ### Can Raft have two leaders at the same time? Two servers can temporarily believe they are leaders in different terms, such as when an old leader is isolated. Raft permits at most one elected leader per term, and its quorum and log rules prevent conflicting committed histories. An isolated old leader can still return stale local reads or issue external requests unless the surrounding system uses safe read protocols and fencing. ## Related concepts - [Consensus algorithms](https://sysround.com/concepts/consensus) - [Leader election](https://sysround.com/concepts/leader-election) - [Quorums](https://sysround.com/concepts/quorums) - [Database replication](https://sysround.com/concepts/replication) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.