Interview Prep Zoneby CuriouserLabs

Question 4 of 5 · architect level

Paxos, Raft, ZAB, Multi-Paxos — how do they differ, and does the choice matter to you?

🎤 Say this first

They solve the same problem with the same majority-quorum core and differ mainly in structure and explicability. Basic Paxos agrees on one value via prepare/promise then accept/accepted — correct, minimal, and famously hard to turn into a system. Multi-Paxos amortizes it by electing a stable distinguished proposer so steady-state writes cost one round-trip — at which point it is essentially Raft with less prescription. Raft fixes a strong leader, a contiguous log, and terms, trading a little flexibility for a specification you can actually implement and debug. ZAB (ZooKeeper) is leader-based like Raft but built around primary order for its state-changes and a recovery phase that syncs followers. In practice, the choice rarely matters to you — what matters is picking a battle-tested implementation and configuring quorum size, timeouts and storage correctly.

The full picture

ProtocolLeaderDistinctive traitShips in
Basic Paxosnone (any proposer)agrees on a single value; dueling proposers can livelocktextbooks; parts of Chubby
Multi-Paxosstable distinguished proposer1 RTT steady state; under-specified in the paperChubby, Spanner, older Google stack
Raftstrong, mandatoryunderstandability as an explicit design goaletcd, Consul, CockroachDB, TiKV, KRaft
ZABstrong, with sync phaseprimary order + recovery-driven follower syncZooKeeper
Viewstamped Replicationstrongthe 1988 original; Raft rediscovered much of itacademic lineage
  • The one real behavioural difference worth citing: leaderless Paxos permits dueling proposers — two proposers repeatedly out-preparing each other and making no progress. Raft's randomized timeouts make that vanishingly unlikely. This is a liveness difference, never a safety one.
  • All of them are safe under partition and all of them stop accepting writes without a majority. If an interviewer is fishing for 'which is more available', the correct answer is that they're identical on that axis, and the real availability differences come from failover speed (timeout tuning) and from client behaviour during elections.
  • EPaxos / Flexible Paxos are where the genuine innovation is: EPaxos is leaderless with commutative fast paths (great for geo-distribution, no leader bottleneck); Flexible Paxos observes that the election and replication quorums need only intersect each other, not both be majorities — which lets you trade write latency against failover cost.
  • The architect's actual decision is almost never 'which protocol' but: how many replicas, spread across how many failure domains, with what election timeout, and — most importantly — what belongs in the consensus system at all. Consensus is for small, critical, low-volume state.
  • Cost of coordination scales badly with distance: a 3-region majority means every write waits for the second-closest region. That single fact drives more architecture (regional sharding, single-region write masters, async cross-region replication) than any protocol choice.

🔄 Likely follow-up questions

  • What is the dueling-proposers livelock, and how does Raft avoid it?
  • Flexible Paxos lets you shrink the replication quorum — what does that cost you?
  • Which parts of a typical microservice platform genuinely need consensus?