Consensus Algorithms: Raft, Paxos and ZAB

The Problem Consensus Algorithms Solves

Without consensus, distributed systems cannot reliably replicate data, elect leaders, or coordinate actions. Consensus is what makes distributed databases (CockroachDB, etcd) and coordination services (ZooKeeper) work correctly.

How It Works Under the Hood

Consensus algorithms enable a group of distributed nodes to agree on a single value or decision, even when some nodes fail. They are the foundation of replicated state machines, distributed databases, and leader election. Key algorithms: Paxos, Raft, and ZAB.

In Raft:

1. Leader election: Nodes start as followers. If a follower does not hear from a leader within a timeout, it becomes a candidate and requests votes. The node with a majority of votes becomes the leader.
2. Log replication: The leader receives client requests, appends them to its log, and replicates to followers. When a majority of followers confirm, the entry is committed.
3. Safety: Raft guarantees that committed entries are never lost, even if the leader crashes. A new leader's log is always at least as up-to-date as any committed entry.

The Mental Model

• The problem: Multiple nodes must agree on a value. Some nodes may crash, messages may be delayed, but the system must still reach agreement.
• Raft: The most understandable consensus algorithm. Leader election + log replication. Used by etcd, CockroachDB, Consul.
• Paxos: The original consensus algorithm by Leslie Lamport. Correct but notoriously difficult to understand and implement.
• ZAB (ZooKeeper Atomic Broadcast): Used by ZooKeeper. Similar to Raft but optimized for primary-backup replication.
• Quorum: Consensus typically requires a majority (N/2 + 1) of nodes to agree. With 5 nodes, 3 must agree (tolerates 2 failures).

Real Systems That Depend on This

etcd (Kubernetes' brain) uses Raft consensus to replicate cluster state across 3-5 nodes.

CockroachDB uses Raft for per-range replication, with each data range having its own Raft group.

Apache Kafka uses ZAB-like protocol for controller election and in-sync replica management.

Where This Shows Up in Interviews

1. What is consensus in distributed systems?
2. How does Raft work at a high level?
3. Why do you need an odd number of nodes?
4. What happens when the leader fails in Raft?

Tradeoffs

• Safety vs Liveness: Consensus guarantees safety (never commits wrong value) but may sacrifice liveness during network partitions.
• Latency: Every write requires a round trip to a majority of nodes. This adds write latency.
• Cluster size: More nodes = higher fault tolerance but slower consensus (more round trips).

Watch Out For

1. Using an even number of nodes — provides no extra fault tolerance over N-1 nodes
2. Deploying all nodes in the same data center — a single failure domain defeats the purpose
3. Not understanding that consensus adds write latency — every write waits for quorum

Go Deeper

• Distributed Locking — start here if this is new to you
• CAP Theorem
• Data Replication
• paxos
• zookeeper

Original DosiBridge notes for Consensus Algorithms: Raft, Paxos and ZAB

This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Consensus Algorithms: Raft, Paxos and ZAB is to connect the concept to a production service where growth exposes the first weak assumption in the original design. That framing changes the design discussion from definitions to operating choices.

What makes this topic distinct

• Membership: For Consensus Algorithms: Raft, Paxos and ZAB, decide the membership before choosing tools; otherwise the design looks clean but fails when consensus changes.
• Clock Drift: For Consensus Algorithms: Raft, Paxos and ZAB, decide the clock drift before choosing tools; otherwise the design looks clean but fails when algorithms changes.
• Retry Semantics: For Consensus Algorithms: Raft, Paxos and ZAB, decide the retry semantics before choosing tools; otherwise the design looks clean but fails when consensus changes.
• Partition Behavior: For Consensus Algorithms: Raft, Paxos and ZAB, decide the partition behavior before choosing tools; otherwise the design looks clean but fails when algorithms changes.
• Reconciliation: For Consensus Algorithms: Raft, Paxos and ZAB, decide the reconciliation before choosing tools; otherwise the design looks clean but fails when consensus changes.

Production review question

If a team adopts Consensus Algorithms: Raft, Paxos and ZAB, what observable signal proves it helped instead of only making the architecture diagram more fashionable?

Practical metric to track

Track consensus-algorithms health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Consensus Algorithms: Raft, Paxos and ZAB, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.