Skip to content

CONCEPT Cited by 1 source

Request versioning

Definition

Request versioning is the assignment of a totally-ordered, time-based version to every in-flight request in a consensus system, so that later electors can resolve conflicts between discovered-but-incomplete requests unambiguously by preferring the newer version. Sugu Sougoumarane canonicalises it as the resolution for the seven propagation failure modes:

"It is safe to propagate the latest discovered decision. A decision to propagate a previous decision is a new decision." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-7-propagating-requests)

This generalises Paxos proposal numbers and Raft term numbers to a single concept, layered one level below the election layer: Part 5's proposal numbers ordered electors competing for leadership; this concept orders requests competing across leadership changes.

The four-step protocol

"(1) Every request has a time-based version. (2) A leader will create its request using a newer version than any previous request. (3) An elector that chooses to propagate an incomplete request will do so under a new version. (4) An elector that discovers multiple conflicting requests must choose to propagate the latest version."

Rule (3) is the subtle and load-bearing one: propagating an old request assigns it a new version rather than preserving the original. This is what keeps the conflict-resolution invariant sound across cascading propagations — if elector A propagates request R under version v₁, and elector B later propagates it again under v₂ > v₁, a third elector can see both and pick v₂ without ambiguity.

Completed requests don't need versioning

"Completed requests do not need versioning."

Structural simplification: once a request is known to be durable + complete, no later elector will ever conflict with it. Only incomplete requests need the version tag. This is the concrete efficiency payoff of separating the completion and propagation concerns.

Why newer-wins is sound

Two corner-case arguments justify the rule:

"If we discover two conflicting requests, it means that the latest request was created because the previous elector did not discover the old one. This essentially means that the old one definitely did not complete. So, it is safe to honor the new elector's decision."

The existence of a newer version is itself evidence that the older one never completed durably — a sound inference because a durable old request would have been discovered by the elector that installed the newer one.

"If we propagate an existing request, it is also under a new version. It will therefore need to satisfy durability requirements under the new version without conflating itself with the old version."

The propagated request has to re-earn durability under its new version; if propagation fails, a later elector sees the original-version's incomplete state alone.

Canonical implementations

  • Paxos: proposal numbers.
  • Raft: leadership term numbers.
  • MySQL replication: GTIDs + timestamps (GTID carries leader identity + counter; timestamp establishes total order). "The MySQL binlogs contain metadata about all transactions. They carry two pieces of relevant information: (1) A Global Transaction ID (GTID), which includes the identity of the leader that created the transaction. (2) A timestamp. This metadata is faithfully propagated to all replicas. This information is sufficient to resolve most ambiguities if conflicting transactions are found due to failures."

Alternative mechanisms

"But you can use other methods for versioning. For example, one could assign timestamps for the requests instead of using leadership terms or proposal numbers."

Any total-ordering mechanism works — Lamport timestamps, hybrid logical clocks, leadership-epoch-plus-sequence tuples, wall-clock with sufficient skew margin. The choice is a performance / clock-sensitivity trade-off orthogonal to the protocol.

MySQL caveat

Sugu flags that MySQL's faithful-propagation of GTIDs breaks rule (3): replicas keep the original leader's GTID + timestamp rather than re-stamping under a new version on propagation. "However, the faithful propagation of the transaction metadata breaks the versioning rule that the decision of a new elector must be recorded under a new timestamp." This violation is compensated by the concepts/anti-flapping layer rather than fixed at the replication layer — a pragmatic engineering trade-off.

Two layers, one mechanism

Reading the series backwards: the same "total-ordered time-like versioning" primitive serves two concerns at two layers:

Layer Concept Purpose
Election concepts/proposal-number Newer-proposal-number elector wins race
Request concepts/request-versioning Newer-version request supersedes conflicts during propagation

Some protocols (Raft) use the same number for both; others (systems with separate lock + propagation layers) can use different mechanisms per layer.

Seen in

Last updated · 347 distilled / 1,201 read