Paxos: The Part-Time Parliament

Historical Context

Leslie Lamport first described Paxos in 1990 using a parable about a fictional Greek parliament on the island of Paxos. The paper was rejected for being too whimsical, so Lamport shelved it. It was finally published in 1998 in ACM Transactions on Computer Systems. Before Paxos, distributed systems lacked a proven, fault-tolerant protocol for reaching agreement among unreliable processes. Two-phase commit existed but could not tolerate coordinator failure. Paxos filled that gap and became the theoretical foundation for nearly every consensus system built since.

Core Problem

How can a group of distributed processes agree on a single value (a log entry, a leader, a configuration change) when any process can crash at any time, messages can be delayed or lost, and there is no shared clock?

Key Innovation

Paxos splits consensus into three roles: Proposers suggest values, Acceptors vote on proposals, and Learners observe the outcome. A proposal succeeds when a majority (quorum) of acceptors agrees, which guarantees that any two quorums overlap by at least one member, preventing conflicting decisions.

The protocol runs in two phases. In Phase 1 (Prepare), a proposer picks a unique, monotonically increasing proposal number and sends a Prepare request to a majority of acceptors. Each acceptor promises not to accept any proposal with a lower number and replies with the highest-numbered proposal it has already accepted, if any. In Phase 2 (Accept), the proposer picks the value from the highest-numbered previously accepted proposal (or its own value if none exists) and sends an Accept request. If a majority accepts, the value is chosen.

This two-phase dance is what makes Paxos safe: even if a proposer crashes mid-protocol, no two different values can both be chosen. Liveness is harder — competing proposers can livelock by continually preempting each other — which is why practical systems elect a distinguished proposer (leader) to drive progress.

Architecture / Algorithm

• Proposal Numbers: Globally unique, monotonically increasing identifiers that impose a total order on proposals.
• Quorums: Any majority subset of acceptors. Overlap between quorums is the key safety property.
• Phase 1 (Prepare/Promise): Establishes a "lease" on a proposal number.
• Phase 2 (Accept/Accepted): Commits a value once a quorum agrees.
• Multi-Paxos: An optimization where Phase 1 is run once for a stable leader, reducing each subsequent consensus round to a single phase.

Strengths

• Provably correct under asynchronous network assumptions
• Tolerates up to F failures with 2F+1 acceptors
• Foundation of virtually all production consensus systems
• Multi-Paxos optimization makes it practical for replicated state machines

Weaknesses

• The original paper is notoriously difficult to understand
• Livelock is possible without leader election
• Performance degrades with many concurrent proposers
• Single-decree Paxos decides only one value; extending to a log (Multi-Paxos) adds complexity that Lamport left under-specified

Modern Systems Influenced

Google Chubby and Spanner use Paxos internally. Apache ZooKeeper's ZAB protocol is a Paxos variant. Raft (used in etcd, Consul, CockroachDB) was designed as an "understandable Paxos." AWS and Azure consensus layers trace back to Paxos ideas.

Interview Relevance

Mention Paxos when discussing leader election, replicated logs, or strong consistency. Know the two-phase structure, why quorum overlap matters, and how Multi-Paxos amortizes overhead. Interviewers value candidates who can explain why majority quorums prevent split-brain rather than just naming the algorithm.

Plain-English Summary

Paxos lets a group of servers agree on one answer even when some servers crash. It works by requiring a majority vote in two rounds: first to lock in a proposal number, then to lock in a value. Because any two majorities share at least one member, conflicting answers cannot both win. Nearly every modern distributed database uses some descendant of Paxos.

Practical Implementation for .NET Developers

In a .NET application, you would typically implement this pattern using the following approach:

ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.

Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core's overhead matters.

Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.

Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.

Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:

Log.Information("Processing order {OrderId} for {CustomerId}", orderId, customerId);

This gives you searchable, structured logs in Azure Monitor or Seq.

Key Takeaways for Interviews

• Understand the core problem this resource addresses and be able to explain it in 2-3 sentences without jargon
• Know the key trade-offs: what does this approach optimize for, and what does it sacrifice?
• Be ready to compare this with alternative approaches and explain when each is appropriate
• Connect the concepts to real-world systems you have worked with or studied
• Demonstrate depth by discussing failure modes and how they are handled

How This Applies to Modern .NET Systems

The concepts from this resource translate to .NET through several established libraries and patterns:

Azure managed services often abstract away the underlying distributed systems complexity, but understanding the fundamentals helps you configure them correctly, debug issues, and make informed architectural decisions.

NuGet packages in the .NET ecosystem provide production-ready implementations of many patterns described in this resource. Before building custom solutions, check if a well-maintained package already exists.

ASP.NET Core middleware pipeline is where many of these patterns are implemented in practice: caching, rate limiting, health checks, and circuit breaking all fit naturally into the middleware model.

Sources

• Paxos Made Simple — Lamport, 2001
• The Part-Time Parliament — Lamport, 1998