PATTERN Cited by 1 source

Pluggable durability rules¶

What it is¶

Pluggable durability rules is an architectural pattern in leader-based consensus systems where the durability requirement ("how many followers / which set of followers must ack a request before the leader considers it durable") is expressed as a configurable plugin over node-set predicates, rather than hard-coded as a majority-quorum assumption in the protocol core.

Sugu Sougoumarane canonicalises it as the first of two architectural recommendations in the closing instalment of Consensus algorithms at scale:

"A consensus system can be designed in such a way that it assumes nothing about the durability rules. These can be specified with a plugin, and the system should be able to fulfill these requirements without breaking integrity. Of course, the requirements have to be reasonable." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts)

The theoretical basis is FlexPaxos (Howard/Malkhi/Spiegelman 2017): majority quorums are a special case of intersecting quorums. Any pair of predicates — one for read/revoke, one for write/durability — where every read set and every write set intersect in at least one node can safely replace majority quorum. The plugin expresses those two predicates as code or configuration, and the consensus core consumes them opaquely.

Why this matters¶

Modern cloud deployments impose durability rules that don't map naturally onto "majority of N nodes":

Cross-zone durability — "at least one ack from each of ≥2 zones" rather than "(N/2)+1 acks total."
Cross-region durability — "at least one ack from a different region."
N-of-M with latency constraints — "any 2 of the 3 fastest followers."
Heterogeneous durability — "writer + one SSD-backed follower + one HDD-backed follower" for cost-tiered storage.

Hard-coded majority-quorum cannot express any of these without lying about the node topology (e.g. adding dummy nodes to force majority math). Pluggable durability lets the topology remain truthful while the rule adapts.

Structural consequence: topology elasticity¶

"A system that supports pluggable durability allows you to deploy additional nodes to the system without majorly affecting its performance characteristics. For example, if you had specified the durability requirement as cross-zone, deploying additional nodes to a zone keeps the system behaving mostly the same way."

Under a zone-durability plugin, adding a replica in an already-covered zone is free — the plugin constrains which intersections are valid, not how many nodes participate. The same cluster can grow from 5 nodes to 50 nodes without any performance regression on the write path as long as the zone coverage is preserved. Topology changes and performance become independent axes.

Under hard-coded majority quorum, adding nodes always affects the write path — the majority count grows with cluster size, and either every write waits for more acks (latency regression) or the protocol skips some acks (correctness regression).

Canonical production instance — Vitess + VTOrc¶

Sugu names Vitess as the canonical worked composition:

"In Vitess, we make full use of the above options and flexibilities. For example, durability rules are a plugin for vtorc. The current plugin API is already more powerful than other existing implementations. You can specify cross-zone or cross-region durability without having to carefully balance all the nodes in the right location."

VTOrc's durability plugin API accepts cross-zone and cross-region rules directly. The comparative claim "more powerful than other existing implementations" is unsubstantiated in the post but frames Vitess as extending beyond upstream Orchestrator's durability handling.

The MySQL replication substrate underneath carries the per-request metadata (GTID + timestamp) that the plugin needs to check durability predicates — no MySQL-protocol modification required; the plugin operates at the VTOrc control-plane layer.

Invariant: reasonable requirements¶

"Of course, the requirements have to be reasonable."

Sugu flags but does not formalise: not every durability rule is satisfiable. The rule must be intersection-preserving — for any valid write set W and any valid read/revoke set R, W ∩ R ≠ ∅. Rules that violate this (e.g. "write to A and B; read from C and D" where {A,B} and {C,D} are disjoint) cannot be protected by any consensus protocol; durability is structurally impossible.

The plugin API is responsible for rejecting unsatisfiable rules at configuration time rather than letting them produce silent split-brain at runtime.

Pluggable durability composes with the other four lock-based advantages from the same Part 8 capstone:

Graceful leader demotion — independent of durability rule.
Easier node addition/removal — explicitly enhanced by pluggable durability (topology elasticity).
Consistent reads — independent of durability rule.
Anti-flapping rules — independent of durability rule.

The two architectural recommendations (pluggable durability + lock-based at scale) are orthogonal; Vitess composes both.

Seen in¶

sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts — canonical wiki introduction of pluggable durability as an architectural pattern; FlexPaxos cited as the theoretical basis ("majority quorum is just a special case of intersecting quorums"); topology-elasticity as the structural consequence; Vitess+VTOrc as the canonical worked production instance with the "more powerful than other existing implementations" comparative claim.