Skip to content

Multi-Leader Replication with Conflict Resolution

Replication protocol — instantiates Shared-State Consistency Contract Design

Lets several replicas accept writes independently for local speed, then reconciles the conflicting versions this inevitably produces with an explicit resolution rule.

Multi-Leader Replication with Conflict Resolution places more than one write-accepting authority in the topology — typically one per region or site — so clients write to a nearby leader without cross-site coordination, and leaders replicate to each other asynchronously. The unavoidable consequence is that the same key can be updated in two places at once, producing divergent versions that must be reconciled. What defines this mechanism is that it owns that conflict problem: it does not try to prevent concurrent writes (that would forfeit the local-write latency it exists for), but commits up front to a conflict resolution rule — last-write-wins, field-level merge, a CRDT, or human review — that every replica applies deterministically so they all converge to the same result.

Example

A company runs a user-profile service in two regions for latency, each with a writable replica. During a brief inter-region partition, a user edits their display name from a phone routed to the EU replica ("Sam Rivera") while a support agent fixes the same field via the US replica ("Samuel Rivera"). Both writes succeed locally — that is the design working. When the link heals, the two versions replicate and collide. The resolution rule decides the outcome deterministically: under last-write-wins the higher timestamp silently wins (and the other edit vanishes); under a field-merge rule the conflict is flagged for the user to pick. The point is that the rule was chosen before the conflict happened, so both regions reach the identical final state rather than diverging permanently.

How it works

The distinguishing pattern is accept-locally-then-reconcile: writes commit at any leader with no global agreement, replicate asynchronously, and conflicts are detected (via version metadata) and resolved by the pre-declared rule so all replicas converge. The engineering decision is not whether conflicts occur — with concurrent multi-site writes they always can — but which rule resolves them and whether that rule preserves the real invariant. Detection of "these two writes were concurrent, not sequential" is delegated to a versioning artifact; this mechanism owns the topology and the resolution policy sitting on top of it.

Tuning parameters

  • Resolution strategy — last-write-wins vs. field merge vs. CRDT vs. human queue: more automation means less operator effort but more risk of silent data loss.
  • Leader topology — all-to-all, ring, or star among leaders: denser links cut propagation delay (fewer conflicts) at higher replication cost.
  • Conflict detection basis — version vectors vs. wall-clock timestamps: vectors are accurate but heavier; timestamps are simple but vulnerable to clock skew.
  • Write affinity — pinning a key's writes to a home region reduces conflicts at the cost of cross-region write latency.
  • Replication lag budget — how far leaders may drift before back-pressure, trading freshness against throughput.

When it helps, and when it misleads

Its strength is local low-latency writes and continued availability under partition — ideal for geo-distributed services and offline-capable clients that must accept writes without reaching a central authority.

It misleads when the resolution rule is chosen for convenience rather than from the invariant. Last-write-wins is the usual culprit: it silently discards the losing concurrent write, so data loss masquerades as consistency, and under clock skew it can even drop the write that actually happened later.[1] Some invariants — a globally unique username, a monotonic sequence — cannot be auto-merged at all, and multi-leader is simply the wrong tool for them. The classic backwards path is adopting multi-leader for latency and treating conflict handling as an afterthought bolted on later. The discipline is to derive the resolution rule from the invariant before deployment, and reserve multi-leader for state that is genuinely merge-friendly.

How it implements the components

  • replica_and_authority_topology — defines a multi-authority (multi-master) layout in which several replicas may accept writes concurrently.
  • conflict_resolution_rule — commits to the deterministic rule that reconciles divergent concurrent writes so all replicas converge.

It does not define the value-level merge types themselves (merge_policy) — those are CRDT-Like State Merge and Last-Write-Wins Register — nor detect which writes were concurrent (version_token, Version Vector); single-authority ordering is Leader-Based Replication.

  • Instantiates: Shared-State Consistency Contract Design — realizes the available, low-latency, conflict-accepting corner of the contract space.
  • Consumes: Version Vector to distinguish concurrent writes from causally-ordered ones.
  • Sibling mechanisms: Version Vector · CRDT-Like State Merge · Last-Write-Wins Register · Leader-Based Replication · Anti-Entropy Synchronization

References

[1] Last-write-wins resolves a conflict by keeping the value with the greater timestamp and discarding the other. Without a causal version scheme it loses concurrent updates unconditionally, and under clock skew it can discard the genuinely later write — which is why the resolution rule must be chosen from the invariant, not for its simplicity. ↩