Stackbook Logo
data-consistencyestablished · medium operational burden

Conflict Resolution

Also known as: write-conflict-resolution, merge-strategies

Intent

Deterministically reconcile concurrent updates to the same data accepted by different replicas or clients.

Problem

When replicas or offline clients accept writes independently, the same record can end up with divergent values. Without a rule, replicas disagree permanently or lose data silently.

Forces

  • •Concurrent writes cannot be ordered by a single authority
  • •Wall clocks across machines are unreliable
  • •Some data merges naturally and some does not
  • •Users expect their edits not to vanish

Solution

Overview

Conflict resolution is the policy that decides what a record's value becomes when two replicas accepted different updates concurrently. It is unavoidable in multi-leader, leaderless, and offline-capable systems, and the policy you choose determines whether users lose data.

How it works

First detect concurrency, then resolve. Version vectors tell you whether one write happened before another or whether they are concurrent siblings.

replica A: cart = {book}        version [A:1]
replica B: cart = {pen}         version [B:1]   (concurrent)

merge(A, B) = union -> {book, pen}   version [A:1, B:1]

Common strategies:

  • Last-write-wins by timestamp: simple but can silently discard writes.
  • Application merge: domain logic such as union of cart items.
  • CRDTs: data types whose merge is associative, commutative, and idempotent.
  • Keep siblings: store both values and let the client or user choose, as CouchDB and Riak allow.

The resolver must give the same result on every replica regardless of order.

Pitfalls

  • Trusting wall-clock timestamps; skew can make the older write win.
  • Using last-write-wins on collaborative or financial data.
  • Merge functions that are order-dependent, causing endless divergence.
  • Purging deletion markers too early, so deleted items return.
  • Not measuring conflict rate. A high rate signals a modeling problem, such as multiple writers to one hot record.

Key takeaways

  • Detect concurrency with causal metadata, not clocks alone.
  • Match strategy to data: LWW, merge, CRDT, or user choice.
  • Make resolution deterministic and order-independent.
  • Prevent conflicts where possible by reducing concurrent writers.

✓ When to Use

  • •Multi-leader or leaderless replication
  • •Offline-first and collaborative applications
  • •Cross-region active-active writes

✗ When Not to Use

  • •Single-writer designs where conflicts cannot occur
  • •Data protected by strong consistency or locks
  • •Cases where conflicts must be prevented, not merged (e.g., unique usernames)

Pros

  • +Allows concurrent writes and high availability
  • +Replicas converge deterministically
  • +Choice of strategy per data type

Cons

  • −Last-write-wins can drop updates
  • −Custom merges are hard to get right
  • −Needs metadata such as version vectors

Cost Profile

Infrastructure

Low: logic in application or database

Operational

Medium: monitoring conflict rates

Cognitive

High: designing correct merge semantics

Failure Modes

  • Clock skew makes last-write-wins pick the older edit

  • Non-commutative merge leaves replicas permanently divergent

  • Resurrected deletes because tombstones were purged too soon

Real-World Examples

Alternatives

  • crdts

Related Patterns

  • crdts
  • vector-clocks
  • multi-leader-replication
  • eventual-consistency
  • optimistic-locking

Competency Domains

data statedistribution communication