Skip to content

PATTERN Cited by 1 source

External metadata for conflict resolution

Intent

Replicate per-transaction metadata (transaction ID + timestamp + leader identity) alongside the transaction itself so that a later coordinator — typically an elector or leadership-change agent — can resolve ambiguities between conflicting transactions without running a protocol round-trip to the original participants.

Motivation

The full per-request-versioning rule (patterns/version-per-request-to-resolve-conflicts) requires that a new elector re-stamps every propagated request under a fresh version. Real production systems like MySQL don't comply with this rule — MySQL's binlog faithfully propagates the original leader's GTID + timestamp to replicas:

"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."

"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." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-7-propagating-requests)

The replicated metadata is externally visible to any agent inspecting the replica — the elector doesn't need to talk to the original leader, the original followers, or re-run a quorum-discovery protocol. It just reads the metadata already sitting in the binlog/replication stream.

Mechanism

  1. Every transaction carries (transaction_id, timestamp, leader_id) (or equivalent tuple).
  2. Replication copies the tuple verbatim to every replica. No rewriting.
  3. On leadership change, the new elector scans the replication stream / binlog / CDC feed and uses the tuple to reconstruct the total order of transactions across the old-new leader boundary.
  4. Conflicts between two transactions are resolved by: (a) newer timestamp wins, (b) leader-id breaks ties, (c) transaction-id closes residual ambiguity.
  5. Corner cases where the tuple alone doesn't suffice are handled by anti-flapping rules that prevent the scenarios from arising often enough to matter.

Why it trades away correctness for practicality

Strict per-request versioning (pattern patterns/version-per-request-to-resolve-conflicts) is formally complete — it resolves all seven propagation failure modes by construction. This pattern is incomplete — there exist failure interleavings where the externally-replicated metadata is ambiguous (e.g., two conflicting transactions with close-enough timestamps and the original leader crashed before committing either). The gap is closed operationally by anti-flapping rather than formally. The trade-off is:

Pattern Correctness Operational cost
Per-request versioning Formally complete Requires protocol changes; every propagation re-stamps
External metadata + anti-flapping Sufficient in practice at MySQL scale Requires out-of-band coordinator (Orchestrator / VTOrc); the residual-correctness-gap is closed by rate-limiting leadership changes

Sugu canonicalises the trade-off explicitly: "Serendipitously, anti-flapping rules also mitigate the failure modes described above. Versioning of in-flight requests is less important for such systems."

Canonical production instance

  • MySQL + Orchestrator: MySQL binlog carries GTID + timestamp; Orchestrator's anti-flapping rules close the propagation-race residual. "This is the reason why organizations have been able to avoid split-brain scenarios while running MySQL at a massive scale."
  • Vitess + VTOrc: VTOrc is a customised fork of Orchestrator; the MySQL GTID + timestamp metadata is inherited unchanged; VTOrc adds Vitess-topology integration (etcd lock + VReplication workflow awareness).

When to apply

  • Replicated log / CDC feed is already the primary data path. If you're shipping a replication stream anyway, the metadata is free — piggyback on the existing propagation layer.
  • Transaction rate ≫ leadership-change rate. The economic argument: making every transaction carry expensive version metadata is worth it only if leadership changes are rare (once-per-day-or-week scale). If leadership changes are more frequent, the per-transaction overhead may not pencil.
  • Anti-flapping is operationally feasible. Requires the operational discipline to impose dwell-times on leadership changes; not all systems have an agent (like Orchestrator) that can enforce this.

When not to apply

  • Strict formal-correctness systems: stick with per-request-versioning (patterns/version-per-request-to-resolve-conflicts).
  • High-frequency leadership changes: anti-flapping can't close the gap if leader churn is faster than the anti-flapping window.
  • No external coordinator: without an agent enforcing anti-flapping, the metadata-only approach loses its safety margin.

Seen in

Last updated · 347 distilled / 1,201 read