# Raft vs Paxos > Raft specifies a leader-based replicated log; basic Paxos chooses one value, and Multi-Paxos extends that foundation to a sequence of decisions. Choose a mature Raft implementation when you want an explicit replication and recovery model, or a mature Multi-Paxos implementation when it fits your storage system and operational requirements better. Source: https://sysround.com/compare/raft-vs-paxos Updated: 2026-11-05 ## Side by side | | Raft | Paxos | |---|---|---| | Scope | Raft: replicated log with election and recovery rules | Basic Paxos: one decision; Multi-Paxos: repeated decisions | | Normal write path | Leader appends and replicates entries | Multi-Paxos leader proposes values for log slots | | Leadership | Terms, election timeouts, log-freshness voting | Ballots and promises; leader selection depends on implementation | | Failure tolerance | With majority quorums, 2f + 1 voters tolerate f failures | Same with standard majority-quorum configurations | | Steady-state coordination | Leader replicates to a majority | Stable Multi-Paxos leader can skip repeated prepare phases | | Recovery | Elected leader reconciles follower logs | New leader gathers accepted state and preserves prior choices | | Membership changes | Includes an overlapping-majority transition approach | Requires a specified reconfiguration protocol | | Read consistency | Linearizable reads need a safe leadership/read protocol | Linearizable reads also need a safe read protocol | ## The differences that matter Compare Raft with Multi-Paxos when discussing a replicated database or log. Basic Paxos selects a value for one consensus instance, not an entire command history. Multi-Paxos uses many instances, usually with a stable leader, to build an ordered log. Comparing Raft's complete log protocol with basic Paxos makes Paxos look less complete because the comparison covers different scopes. Raft constrains leadership through voting rules: a candidate must have a sufficiently up-to-date log to win. Followers reconcile conflicting suffixes with the leader's log. In Multi-Paxos, a new leader uses a higher ballot and collects accepted state from a quorum, then preserves values that may already have been chosen. These are different recovery mechanisms for maintaining agreement across leader changes. Neither protocol has an inherent steady-state latency advantage just because of its name. A stable Multi-Paxos leader can avoid repeating the prepare phase for each slot, giving it a coordination pattern similar to Raft's leader-to-quorum replication. Disk persistence, batching, pipelining, quorum placement, and implementation details determine the actual write latency and throughput. Raft makes more of the replicated-log design explicit, including log matching, election restrictions, and a membership-transition approach. A system described only as Paxos still needs choices for log management, reconfiguration, snapshots, catch-up, and reads. Raft implementations also need careful engineering in these areas; a clearer specification does not remove operational complexity. Both preserve agreement under the assumed crash-failure model, but neither guarantees progress through every network partition or indefinitely delayed network. In standard majority configurations, a partition without a majority cannot commit new writes. Neither protocol alone gives linearizable follower reads, exactly-once external side effects, or transactions across independent consensus groups. ## Choose Raft when - You need a replicated metadata store or log and want a protocol with explicit election, replication, and recovery rules. - Your team can operate a mature Raft-based library or storage system with suitable persistence, backup, and recovery behavior. - In an interview, you need to explain a concrete write path and safe failover without leaving the replicated-log protocol unspecified. - Your membership-change requirements are supported by the implementation's tested Raft reconfiguration mechanism. ## Choose Paxos when - An existing storage platform already has a mature Multi-Paxos implementation that meets your consistency and operational requirements. - You are extending a Paxos-based system, and replacing its consensus layer would add risk without solving a demonstrated problem. - You need specialized quorum or protocol behavior supported by a well-specified Paxos variant, and can explain its additional assumptions. - The discussion is about agreement on a single value rather than maintaining a full replicated command log, making basic Paxos the relevant abstraction. ## Worked example: A three-voter database control plane Suppose a database control plane stores shard ownership in three voting replicas, one per availability zone. It receives 200 metadata updates per second and must tolerate one unavailable zone. With Raft or standard Multi-Paxos, a write needs a majority of two voters, so the isolated single-voter side cannot commit ownership changes. If the leader fails after an update is committed but before replying, the client may retry; a request ID prevents applying the logical operation twice. Choose the mature implementation your team can operate, not an assumed speed advantage. Separately, issue fencing tokens so an old shard owner cannot keep writing after ownership changes. ## In the interview - Start with the invariant: replicas must agree on the committed command order, and acknowledged durable writes must survive the failures you claim to tolerate. Then explain why consensus is needed for that part of the system. - Clarify that your practical comparison is Raft versus Multi-Paxos. State the number of voters, the quorum size, and which failure domains contain them. - Walk through leader failure after replication but before the client receives a response. Expect questions about recovering the chosen command, retry deduplication, and why a timeout does not prove failure. - Explain how reads stay linearizable. A leader must establish its authority and apply the required committed state; a follower cannot simply serve its local state as current. - Describe what consensus does not solve. Interviewers may probe fencing stale workers, coordinating transactions across shards, membership changes, and restoring service after quorum loss. ## Common mistakes - Claiming Paxos always needs two coordination phases per write. A stable Multi-Paxos leader can amortize the prepare phase across many decisions. - Claiming Raft is inherently faster, or Paxos is inherently more fault tolerant. Protocol variants, quorum choices, persistence, and implementation details matter. - Treating leader election as sufficient for safe replication. Election and recovery must preserve previously committed or chosen values. - Assuming consensus provides exactly-once execution or prevents every stale leader from affecting external systems. Retry deduplication and fencing are separate design concerns. ## Interview questions where it comes up - [Design a distributed key-value store](https://sysround.com/questions/design-key-value-store): Consensus determines how a strongly consistent shard replicates writes, preserves acknowledged data, and handles leader failure. - [Design a distributed message log like Kafka](https://sysround.com/questions/design-kafka): Raft or Multi-Paxos can establish partition log order and preserve committed entries across replica failover. - [Design a control plane for a distributed database](https://sysround.com/questions/design-database-control-plane): Consensus-backed metadata supports durable ownership decisions and safe control-plane failover, with fencing for external actions. - [Design a distributed message queue like RabbitMQ](https://sysround.com/questions/design-message-queue): Replicated queue state needs a defined commit point and recovery rules without confusing replication with exactly-once processing. - [Design a distributed job scheduler](https://sysround.com/questions/design-job-scheduler): Consensus can serialize scheduler ownership and durable dispatch decisions, while worker leases and duplicate side effects need separate handling. ## FAQ ### Is Raft easier to understand than Paxos? Raft was designed to make replicated consensus easier to understand by separating leader election, log replication, and safety rules. It also describes more of the replicated-log system than basic Paxos does. That helps explanation, but production correctness still depends on persistence, recovery, reconfiguration, and implementation details. ### Is Raft faster than Paxos? There is no universal winner. With a stable leader, Raft and Multi-Paxos can both commit writes through leader-to-quorum communication. Compare actual implementations under the same durability, batching, network, and failure-recovery requirements. ### Do Raft and Paxos prevent split-brain? Under their assumptions, correct implementations prevent conflicting committed decisions, even when multiple nodes believe they should lead. In standard majority configurations, two disjoint partitions cannot both form a write quorum. External resources still need fencing if stale leaders or workers can act outside the consensus-backed state machine. ## Related concepts - [Consensus algorithms](https://sysround.com/concepts/consensus) - [Raft](https://sysround.com/concepts/raft) - [Paxos](https://sysround.com/concepts/paxos) - [Quorums](https://sysround.com/concepts/quorums) - [Leader election](https://sysround.com/concepts/leader-election) --- 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.