Consensus is best seen not as a badge of engineering sophistication, but as an expensive tool for the cases where the system truly needs one agreed state history.
In practice, this chapter helps separate situations where Raft or Paxos are justified from those where the team is only buying extra latency and complexity without gaining anything critical in correctness.
In interviews and architecture discussions, it is strongest when you talk less about algorithm names and more about the cost of quorum: write latency, recovery behavior, leader failover, and debugging overhead.
Practical value of this chapter
Design in practice
Clarifies where consensus is truly required versus where simpler guarantees are enough.
Decision quality
Helps choose Raft/Paxos with awareness of workload shape and fault-tolerance goals.
Interview articulation
Enables concise explanation of quorum, term, and commit behavior.
Risk and trade-offs
Highlights consensus cost: write latency, recovery complexity, and debugging overhead.
Related book
Designing Data‑Intensive Applications
The chapter on consensus and replication is a must-read for understanding Paxos/Raft.
Consensus is a way to agree on a single meaning in a distributed system despite failures, delays and network divisions. Without consensus, you cannot reliably elect a leader, synchronize metadata, or provide linear writes to a quorum cluster.
Foundation
TCP protocol
Consensus relies on network rounds and stable transport.
Where is consensus needed?
Leader selection
Cluster coordination and coordinator/primary assignment.
Metadata
Configurations, membership, data schema and routing.
Consistent entry
Linearizable operations during replication.
Paxos
Paxos is a classic Lamport algorithm. It guarantees the selection of a single value through a two-phase protocol and quorum acceptors. In real systems, Multi-Paxos with a dedicated leader is often used.
Interactive Paxos diagram
Select a step to highlight active participants and messages.
Multi‑Paxos
Paxos optimization for command flow: the leader takes on the Prepare phase once, and then only performs the Accept round for each entry.
What does it give
- Fewer network rounds per entry
- Higher throughput
- The Leader Makes Progress Easy in Conflicts
Multi‑Paxos operation modes
Select a phase to see how the message flow changes.
Each new log entry uses only the Accept round, reducing RTT.
Raft
Raft was designed to be a "understandable consensus". It divides the task into leader election, log replication, and membership management. This makes the protocol easier to explain and implement.
Raft node states
Switch state to see how node role and message flow change.
Accepts client commands and replicates them to followers.
Paxos vs Raft
Paxos
- More difficult to understand and implement
- More formal and "academic"
- Often hidden behind Multi‑Paxos
Raft
- Easier to explain to the team and support
- Explicit leader-centered model
- Used in etcd, Consul, CockroachDB
Key Findings
- Consensus is needed for consistent value selection in the face of disruption.
- Paxos is fundamental but complex; Raft is engineering friendly.
- Both protocols require a majority quorum and are tolerant of partial failures.
Consensus makes the system more reliable, but increases latency and complexity. Use it only where strict consistency is truly needed.
Related chapters
- Why distributed systems and consistency matter - Section map with baseline failure models, coordination challenges, and consistency trade-offs.
- CAP theorem - Fundamental partition trade-off that defines the boundary conditions for consensus protocols.
- PACELC theorem - CAP extension showing how latency vs consistency trade-offs influence consensus-driven architecture choices.
- Clock synchronization in distributed systems - How skew and time drift impact timeout tuning, leader election, and protocol stability.
- Leader election patterns and implementations - Practical failover, lease, and split-brain protection patterns built around consensus primitives.
- Distributed transactions: 2PC and 3PC - How cross-service consistency coordination complements consensus-based state replication.
- Jepsen and consistency models - Methods to validate consistency guarantees and detect anomalies in production-like cluster tests.
- Designing Data-Intensive Applications (short summary) - Key source on replication logs, consensus context, and practical distributed-system trade-offs.
- Distributed Systems: Principles and Paradigms (short summary) - Classic theoretical foundation for distributed algorithms, consensus, and failure models.
- Leslie Lamport: causality, Paxos, and engineering mindset - Historical and practical context of the ideas that shaped Paxos and modern consensus design.