Paxos Role Decomposition (Proposer/Acceptor/Learner)

Lamport's original three-role decomposition of the Paxos consensus protocol (proposer/acceptor/learner), argued to map structurally onto modern disaggregated-systems roles (compute/log-store/page-store) — a resemblance obscured for decades by Multi-Paxos/Raft's compaction of the roles.

Also known as: proposer-acceptor-learner, compartmentalized Paxos, Paxos roles, consensus role separation

Documents (1)

• Presentation: Parting the Clouds: The Rise of Disaggregated Systems Murat Demirbas · 2026-07-30 source ↗ Reader 🖥️
  Cloud economics (the differing cost, scaling, and statefulness profiles of compute versus storage) is forcing database architectures toward disaggregation, and this shift is not a novel invention but a rediscovery of Lamport's original three-role decomposition of Paxos (proposer/acceptor/learner) — so the tradeoffs, optimizations, and open problems of today's disaggregated systems can be understood, and addressed, through decades of prior consensus-protocol research.

Propositions touching this concept (1)

By publication month, oldest first (extraction month when no publication date is known).

2026-07

• explicitcorroboratedBecause acceptors need only 2f+1 for quorum/no-split-brain while proposers and learners need only f+1, replicating uniformly across all roles (as Raft effectively does once roles are merged) is more redundant than the classical Paxos role decomposition requires — and decades of Paxos flexible-quorum research can be reused to improve disaggregated database throughput.
  Presentation: Parting the Clouds: The Rise of Disaggregated Systems · p8

Open gaps (4)

• incompleteThe talk's central analogy (Paxos's proposer/acceptor/learner = disaggregated compute/log-store/page-store) is argued from role-count and role-function correspondence, but never examines whether the actual consistency and safety mechanisms engineered into commercial systems — Aurora's specific 4-of-6 storage quorum, PolarDB's 'parallel Raft' — were derived from, or are even formally equivalent to, Paxos's quorum-based correctness guarantees. It is left unclear whether this is a rigorous technical lineage or a structural resemblance noticed after the fact and narrated as history.
  Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Compare the Aurora and PolarDB architecture papers' own consistency arguments against Lamport's Paxos correctness proof, to see whether their quorum choices were derived from consensus theory or arrived at independently by systems engineers optimizing empirically for latency and durability.
• incompleteThe claim that 'decades of Paxos research... can be borrowed' to improve disaggregated database throughput is illustrated only by the author's own separate research prototype (compartmentalized Paxos, an 8x throughput result over the same codebase) — not by evidence that any of the three surveyed commercial systems (Aurora, PolarDB, TaurusDB) actually apply flexible quorums or role-disaggregated consensus in production.
  Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Read the compartmentalized Paxos paper (Demirbas et al. with UC Berkeley collaborators) and any public engineering retrospectives from the Aurora/PolarDB/TaurusDB teams to check whether flexible-quorum results have moved from research into production, or remain a proposal.
• incompleteThe list of production disaggregated systems (Aurora 2015 through Amazon DSQL 2025) is presented as confirmatory evidence that disaggregation 'is already here' and validated, with no counter-examples, documented cost overruns, performance regressions, or teams that reverted from disaggregated to monolithic designs — a one-sided evidentiary base for what is framed as an economically inevitable trend.
  Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Look for independent benchmarks or critical retrospectives comparing Aurora/PolarDB/AlloyDB total cost of ownership and performance against self-hosted or lift-and-shift Postgres/MySQL, to test whether 'cloud economics demands disaggregation' holds outside an idealized cost model.
• illogicalThe 'ingrained fault tolerance' principle (build consensus into the database rather than depend on an external configurator) is asserted without reconciling that internalizing consensus reintroduces the coordination overhead that motivated separating log stores and page stores from compute in the first place. The author himself concedes the shared-log/virtual-log research branch he praises still depends on an external metastore ('I'll live with it'), which undercuts the principle's own claim to full self-containment without resolving the tension.
  Presentation: Parting the Clouds: The Rise of Disaggregated Systems — read next: Read Mahesh Balakrishnan's shared-log/virtual-log work for how it explicitly handles this exact tradeoff, rather than fully internalizing consensus — it may show that full self-containment is not achievable in practice and 'ingrained fault tolerance' is aspirational rather than a settled design principle.