Conflict Resolution Strategies

📘 Chapter 9: Consistency & Distributed Consensus ⏱️ 9 min read 🏗️ Lesson 039

In any distributed system with multiple replicas accepting writes, conflicts are inevitable. Two clients update the same data simultaneously on different nodes. When those nodes sync up, which value wins? The answer depends on your conflict resolution strategy — and there's no single right answer.

When Conflicts Arise

Conflicts happen when:

  • Two clients write to the same key on different replicas (multi-leader or leaderless replication)
  • A network partition heals and replicas have divergent state
  • Multiple users edit the same document simultaneously (collaborative editing)

Strong consistency avoids conflicts by forcing all writes through one leader — but that costs availability and latency. If you choose eventual consistency, you must have a conflict resolution strategy.

Last-Write-Wins (LWW)

Simple But Lossy

Attach a timestamp to each write. When replicas sync, the write with the latest timestamp wins; the other is silently discarded.

  • Pros: Simple to implement, deterministic, converges quickly
  • Cons: Data loss — the "losing" write disappears forever. Clock skew can make the "wrong" write win.
  • Use when: Data loss is acceptable (cache values, sensor readings, session data)
Last-Write-Wins — Data Loss Example Client A (Node 1) SET name = "Alice" t = 10:00:01.000 Client B (Node 2) SET name = "Bob" t = 10:00:01.002 LWW Result: name = "Bob" wins ⚠️ "Alice" is lost forever! Client A gets no error — thinks write succeeded
Figure 1: LWW picks the later timestamp. Client A's write is silently discarded — both clients think their write succeeded.

Vector Clocks

Detect Conflicts Without Losing Data

Instead of a single timestamp, each node maintains a vector of counters — one per node. This lets the system detect when writes are concurrent (neither happened before the other) vs causally ordered (one happened after the other).

  • If vector A ≤ vector B component-wise → A happened before B (no conflict)
  • If neither A ≤ B nor B ≤ A → concurrent writes → conflict detected
  • Conflicts are preserved and passed to application or user for resolution

Used by: Amazon Dynamo (original paper), Riak

CRDTs (Conflict-free Replicated Data Types)

Data Structures That Merge Automatically

CRDTs are specially designed data structures where all concurrent operations can be merged without conflicts. The merge operation is commutative, associative, and idempotent.

  • G-Counter: Grow-only counter. Each node tracks its own increments. Merge = sum all nodes' values.
  • PN-Counter: Supports increment and decrement (two G-Counters: one for adds, one for removes).
  • G-Set: Grow-only set. Merge = union.
  • OR-Set (Observed-Remove Set): Supports add and remove. Tags each element with a unique ID.
  • LWW-Register: A CRDT version of last-write-wins for single values.
CRDT Counter — Automatic Conflict-Free Merge Replica A A's count: 3 (incremented 3x) B's count: 0 (hasn't seen B) Local view: total = 3 Replica B A's count: 0 (hasn't seen A) B's count: 5 (incremented 5x) Local view: total = 5 After Merge A=3, B=5 → total = 8 ✓ No data lost! Both increments preserved. Merge = max(each node's counter).
Figure 2: A G-Counter CRDT — each replica tracks its own increments. Merge takes the max of each node's counter, giving the correct total.

Application-Level Resolution

Let the Application (or User) Decide

When automatic resolution isn't appropriate, present conflicts to application logic or the end user:

  • Git merge conflicts: When two branches modify the same line, Git asks the developer to resolve manually
  • Google Docs: Uses Operational Transformation (OT) — transforms concurrent edits so they can all be applied in any order and produce the same result
  • Custom business logic: "If two users book the same slot, the one who paid first wins"

Real-World Examples

🏢 Google Docs — Operational Transformation

Google Docs lets dozens of users edit simultaneously without conflicts:

  • Each edit is an operation (insert char at position X, delete range Y-Z)
  • When concurrent edits arrive, the server transforms them: if User A inserts at position 5 and User B inserts at position 3, then A's position shifts to 6 (because B's insert pushed everything right)
  • All clients converge to the same document state regardless of the order operations arrive
  • This is not a CRDT — it requires a central server to order operations

🏢 Figma — CRDTs for Collaborative Design

Figma uses CRDTs to enable real-time collaborative design:

  • Each design element (rectangle, text, etc.) is a CRDT that can be independently modified
  • Moving an element on one client while another changes its color → both changes merge cleanly (different properties)
  • For conflicting changes to the same property (two users resize the same box) → LWW per property
  • No central authority needed for conflict resolution — peers can sync directly

🏢 Amazon Shopping Cart — Favor Adds

Amazon's Dynamo-based cart resolves conflicts with a business rule:

  • If replicas diverge (one has item X, another doesn't), take the union — keep the item
  • Rationale: a "phantom" item in cart is a minor annoyance (customer removes it); a lost item is a lost sale
  • This is domain-specific: "when in doubt, favor the action that leads to revenue"

Interactive: Conflict Resolution Simulator

Two clients write to the same key concurrently. Choose a resolution strategy:

Client A (Node 1)
—
Client B (Node 2)
—