paxos for system builder
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Paxos is a fundamental algorithm for achieving consensus among distributed systems or nodes with high reliability, even in the face of failures. Developed by Leslie Lamport in the 1990s, its importance in distributed computing cannot be overstated, influencing a myriad of systems that require fault tolerance and data consistency across nodes that might fail or be partitioned.
Understanding Paxos Fundamentals
Paxos helps a cluster of participants agree on a single value among potentially many proposed values. It is used extensively to ensure consistency in distributed systems, from distributed databases and filesystems to blockchain technology.
The protocol is designed to operate even when some participants (or "acceptors" in Paxos terminology) fail or are unreachable, as long as a majority of them are operational. The overall process can be decomposed into two main phases:
- Prepare/Promise Phase
- Accept/Notification Phase
Phase 1: Prepare/Promise
- A participant, acting as a "proposer", selects a proposal number and sends a prepare request with to a majority of acceptors.
- Upon receiving a prepare request, an acceptor must respond with a promise not to accept any more proposals numbered less than . If the acceptor has already accepted a proposal, it must include the prior accepted proposal’s number and value in its response.
Phase 2: Accept/Notification
- If the proposer receives a majority of promises from a quorum of acceptors, it needs to set a value for its proposal:
- If any acceptors have previously accepted any proposal, the proposer must use the value of the highest-numbered proposal among them.
- If none of the acceptors have accepted a proposal, the proposer can choose any value.
- The proposer sends an accept request to a quorum of acceptors with the proposal number and the chosen value.
- Each acceptor can accept this proposal unless it has already promised to a higher-numbered proposal, and then notifies the proposer of its acceptance.
Ensuring Consistency and Liveness
Paxos ensures that a value once chosen can be learned by any participant, even if there are failures. However, the algorithm does not guarantee liveness – that consensus is reached, because it's possible for participants to continually outbid each other with higher-numbered proposals without convergence.
Practical Implementations and Optimizations
In real-world applications, several optimizations can be employed to make Paxos more efficient:
- Multi-Paxos: By electing a single leader to act as a proposer for a sequence of Paxos rounds, the overhead of choosing proposers for each decision can be reduced.
- Batching: Proposals can include batches of operations rather than a single operation, reducing the overhead per operation.
Below is a table summarizing the key aspects of Paxos:
| Aspect | Detail |
| Fault Tolerance | Can tolerate up to failures among acceptors. |
| Consistency | Guarantees that all nodes that reach a decision will decide on the same value. |
| Liveness | Does not guarantee that a decision will be reached (consensus can be indefinite). |
| Communication Complexity | Each round involves multiple rounds of communication between proposers and a majority of nodes. |
| Scalability | Generally scales well with the number of participants in terms of fault tolerance. |
| Use Cases | Distributed databases, replicated file systems, blockchain systems, etc. |
Conclusion
Paxos is a powerful but complex protocol for achieving distributed consensus. Practical deployments need to carefully manage the trade-offs of complexity, performance, and reliability. Understanding and implementing Paxos can significantly enhance the robustness of distributed systems, ensuring they perform reliably even under failure conditions.
Related reading
- Paxos leader election might not terminate
- Paxos questions if proposer down, what happened?
- Paxos understanding
- paxos vs raft for leader election
- paxos why do ids have to increase monotonically?
- PBFT consensus algorithm and double spending
- PBFT view-change What happens to committed operations after the valid snapshot?
- PBFT Why cant the replicas perform the request after 2/3 have prepared? why do we need commit phase?

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.