Skip to content

Quorum or Consensus Commit

Commit protocol — instantiates Assumption-Bounded Distributed Agreement

Turns a proposed value into an authoritative, irreversible decision the instant an intersecting quorum has acknowledged it — and treats anything short of that as still undecided.

Quorum or Consensus Commit is the base act the whole archetype is built around: taking a proposed value and making it the decision once — and only once — enough participants have acknowledged it. Its defining idea is quorum intersection. Agreement is not defined by "a majority said yes" but by choosing acknowledgement sets so that any two of them must overlap in at least one participant; because a single honest participant cannot acknowledge two conflicting values, two conflicting proposals can never both assemble a quorum. That is what lets a participant act on a local "enough yeses" and still be globally safe. The second half of the mechanism is the commitment boundary: before the quorum forms the value is provisional and may still change; at the instant it forms, the value becomes durable and irreversible. Everything else in the archetype exists to make that instant safe — this mechanism is the instant itself.

Example

A globally replicated configuration store keeps a single authoritative value for "which region currently serves writes," mirrored across five replicas in five data centers. An operator proposes switching the active region; another operator, unaware, proposes switching it somewhere else at nearly the same moment. Each proposal is broadcast and replicas acknowledge. The commit rule is a simple majority — three of five. The first proposal collects acknowledgements from replicas in three centers and, at that third acknowledgement, commits: the value is now the decision, durable and not up for revision. The competing proposal can now never reach three, because any three replicas it might gather must overlap the first quorum, and those overlapping replicas have already promised the first value. The losing operator's request comes back "superseded — retry against the new value." Before that third acknowledgement, a client that read the old region was not wrong; it simply read a pre-commit state. After it, every quorum read is guaranteed to see the one committed value.

How it works

  • Count by intersection, not by count. The quorum rule is chosen so every two acknowledgement sets share a member (a majority, or read/write quorums with W + R > N). Intersection — not the raw number — is the safety property.
  • Two states, one boundary. A value is proposed (revisable) until a quorum acknowledges, then committed (durable) forever after. The transition is atomic and monotone: a committed value is never un-committed.
  • Terminate honestly. The round ends when a quorum is reached (decided) — and if one cannot be assembled, it stays undecided rather than lowering the bar to manufacture a decision.

It deliberately does not order competing proposals across rounds, sign its messages, or tolerate lying — it is the quorum-and-commit core those richer protocols wrap.

Tuning parameters

  • Quorum size / read-write split — a symmetric majority, or an asymmetric W/R pair with W + R > N. Larger write quorums make writes safer but slower and less available; larger read quorums do the reverse.
  • Weighting — equal votes versus weighted or hierarchical quorums (some replicas count more). Weighting tunes for heterogeneous or geographically-tiered replicas but complicates the intersection proof.
  • Durability before acknowledgement — whether a replica must persist (fsync) a value before acknowledging or may ack from memory. Stronger durability makes "committed" mean more, at latency cost.
  • Behaviour on quorum-not-reached — abort, hold, or retry. This is the dial that decides how the commit fails when too few replicas are reachable.

When it helps, and when it misleads

Its strength is a safety guarantee that is almost embarrassingly simple and completely protocol-agnostic: if quorums intersect, no two conflicting values can both commit, full stop. It also makes the commitment boundary an explicit, nameable instant — invaluable when reasoning about what a client could have observed.

It misleads in three classic ways. It assumes crash faults and honest acknowledgements — a single participant that acknowledges two conflicting values breaks intersection and needs a Byzantine-tolerant protocol instead. It requires a live quorum to make progress, so a partition that leaves every side short of a quorum will (correctly) block: you cannot have commit-safety and availability during a partition at once.[1] And "committed" is only as strong as the durability the acknowledgement promised. The signature misuse is shrinking the quorum under availability pressure — accepting two-of-five "just this once" — until two disjoint quorums can form and split-brain becomes possible. The discipline is absolute: never let quorums stop intersecting, and size them against the failure budget, not the outage you are panicking about.

How it implements the components

  • agreement_value_contract — defines what is being agreed and guarantees that a committed value is the single authoritative decision consumers may build on.
  • quorum_or_voting_rule — the intersecting-quorum counting rule (majority, or W + R > N) that decides when enough acknowledgements exist to commit.
  • commitment_boundary — the exact proposed→committed instant: revisable before, durable and irreversible after.
  • termination_condition — quorum reached ⇒ decided; otherwise the round ends undecided rather than guessing.

It does not mint the durable, transferable evidence of a decision (that is Signed Quorum Certificate), tolerate lying participants (Byzantine Fault-Tolerant Quorum Protocol), or order competing proposals across rounds (Paxos-Style Quorum Protocol).

Notes

The commit is safe only while quorums intersect. That single invariant is why membership can never be changed by editing a config file on each node independently — a careless change can create a window in which the old and new participant sets form two disjoint quorums. Preserving intersection across such changes is exactly the job handed to Joint-Consensus Membership Change.

References

[1] Quorum intersection is the property that any two quorums share at least one member; it is the elementary reason majority-based commit is safe. Its unavoidable cost is that when no side of a partition holds a quorum, progress must stop — the tension a partitioned system cannot escape. ↩