Why does Paxos ensure that consensus is reached and does not change?
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Paxos is a protocol for solving consensus in a network of unreliable processors (commonly referred to as nodes). Consensus algorithms are essential for ensuring that multiple nodes agree on a single data value, which is vital in distributed systems where nodes must agree on the state of a shared system despite failures and message losses.
How Paxos Works
Paxos operates through a series of phases that allow a collection of nodes to reach an agreement even if some nodes fail or messages are delayed. The core idea behind Paxos can be broken down into three main phases:
- Prepare: A proposer selects a proposal number and sends a prepare request with to a majority of acceptors.
- Promise: Acceptors respond to the prepare requests. An acceptor must respond to this request if it has not responded to any prepare request with a number greater than . The response is a promise that the acceptor will not accept any more proposals numbered less than , and it includes the highest-numbered proposal (if any) that the acceptor has already accepted.
- Accept: If the proposer receives a response from a majority of acceptors, it sends an accept request for a proposal , where is the value of the highest-numbered proposal among the responses, or a new value if none were previously accepted. The acceptors then accept this proposal unless they have already responded to a prepare request with a higher number.
Ensuring Consensus
Paxos ensures that consensus is reached and does not change due to several critical properties:
- Safety: Even if some nodes fail or do not respond, as long as a majority can still communicate, the protocol guarantees that consensus will not be violated. At most one value can be chosen, and once a value is chosen, the nodes will not agree on a different value.
- Liveness: Paxos guarantees that if participants follow the protocol and can communicate (i.e., messages are eventually delivered), then the protocol will eventually complete, and a value will be chosen.
- Fault Tolerance: Up to almost half of the nodes can fail (specifically, any minority), and the system will still function. This results in Paxos being highly suitable for distributed systems where node failures can be common.
Performance and Practical Concerns
While Paxos guarantees that consensus will be reached, its performance can be affected by network conditions and node failures. The need for multiple rounds of messages between a majority of nodes can lead to delays, especially in large or geographically dispersed networks.
Table of Key Concepts
| Term | Description |
| Proposer | Node that initiates the consensus by proposing values. |
| Acceptor | Nodes that respond to proposals and decide to accept/reject them. |
| Learner | Nodes that receive the decision on the proposed value from acceptors. |
| Quorum | A majority of nodes; essential for decisions to be made. |
| Proposal Number | A unique identifier for proposals which determines the sequence of decision-making. |
Summary
The Paxos protocol is robust against node failures and network partitions, making it a reliable method for achieving consensus in distributed systems. Its resilience comes from the requirement for a majority quorum wherein as long as a majority of nodes can communicate, they can reach and maintain a consistent agreement. The protocol's deliberate design ensures that once consensus is achieved on a particular value, it will not revert or change.
By ensuring that no single point of failure can disrupt the consensus, and requiring multiple rounds of confirmation among a majority, Paxos provides a solution that, despite potential performance drawbacks in terms of latency and operational overhead, remains one of the pillars of fault-tolerant computing in distributed environments.
Related reading
- Why does simple 3-way majority voting not solve Byzantine faults?
- Why exactly isn't MEF a DI/IoC container?
- Why Hazelcast CacheLoader class needs to be visible by all clients?
- Why implement non idempotent operations?
- Why does QuickSort use Ologn extra space?
- Why does radix sort have a space complexity of Ok n?
- Why in chord p2p system, the finger table don''t store all the information about the other nodes?
- Why is 2-phase commit not suitable for a microservices architecture?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.