Patterns

35 items

System Design Pattern

Consistencyconflict-resolutionlwwcrdtvector-clocksmergeadvanced

Conflict Resolution Pattern

Handling concurrent updates in distributed systems

Used in: Collaborative Editing, Multi-region DBs, Offline Apps|25 min read

Summary

Conflict resolution handles the situation when multiple writers update the same data concurrently in distributed systems. Without coordination, concurrent writes can cause data loss or inconsistency. Strategies include: Last-Write-Wins (simple but lossy), application-level merge (custom logic), CRDTs (mathematically guaranteed convergence), and operational transforms (used by Google Docs). The right strategy depends on your data semantics - counters can use CRDTs, documents need operational transforms, and shopping carts can merge sets. This pattern is essential for any system with multiple writers, including multi-region databases, offline-capable apps, and collaborative editing.

Key Takeaways

Concurrent Writes Are Inevitable

In distributed systems, writes can happen simultaneously on different nodes. Network partitions mean nodes can't always coordinate. You must handle conflicting writes - the question is how.

Last-Write-Wins is Lossy

Using timestamps to pick 'latest' write is simple but discards data. If user A adds item and user B changes quantity simultaneously, one change is lost. Acceptable for some data, dangerous for others.

CRDTs Guarantee Convergence

Conflict-free Replicated Data Types are data structures that mathematically guarantee all replicas converge to same state. No coordination needed. Used by Redis, Riak, and collaborative apps.

Scenario: Multi-region database

User in US updates profile: `name = "Alice"`
User in EU updates profile: `name = "Alicia"` (same user, different device)
Both writes happen during network partition
When partition heals, which value wins?

Without conflict resolution: - Arbitrary winner based on arrival order - Or database rejects one write (unavailable) - Or data becomes inconsistent across regions

Concurrent Write Conflict

Summary

Key Takeaways

Concurrent Writes Are Inevitable

In distributed systems, writes can happen simultaneously on different nodes. Network partitions mean nodes can't always coordinate. You must handle conflicting writes - the question is how.

Last-Write-Wins is Lossy

CRDTs Guarantee Convergence

Conflict-free Replicated Data Types are data structures that mathematically guarantee all replicas converge to same state. No coordination needed. Used by Redis, Riak, and collaborative apps.

Operational Transforms for Documents

OT transforms concurrent operations to apply cleanly. If user A inserts at position 5 and user B deletes at position 3, OT adjusts A's position to 4. Powers Google Docs and real-time collaboration.

Application Semantics Matter

Best resolution strategy depends on data meaning. Shopping cart: merge items (union). Counter: sum values (add-only). User profile: per-field merge. One size does not fit all.

Detect Before Resolve

Use vector clocks or version vectors to detect conflicts. Only resolve when actual conflict detected. Most writes don't conflict - optimize for the common case.

Pattern Details

Scenario: Multi-region database

User in US updates profile: `name = "Alice"`
User in EU updates profile: `name = "Alicia"` (same user, different device)
Both writes happen during network partition
When partition heals, which value wins?

Without conflict resolution: - Arbitrary winner based on arrival order - Or database rejects one write (unavailable) - Or data becomes inconsistent across regions

Concurrent Write Conflict

Trade-offs

Aspect	Advantage	Disadvantage

Patterns

Horizontal Scaling Pattern

Retry with Backoff Pattern

Queue-based Load Leveling Pattern

Replication Pattern

Caching Strategies Pattern

Fan-out Pattern

Fan-in Pattern

Persistent Connections Pattern

Load Balancing Pattern

Circuit Breaker Pattern

Bloom Filters Pattern

Time-Series Storage Pattern

Bulkhead Pattern

Batch Processing Pattern

Write-Ahead Log Pattern

API Gateway Pattern

Backend for Frontend Pattern

Sidecar Pattern

Idempotency Pattern

Rate Limiting Pattern

Backpressure Pattern

Pub/Sub Pattern

Eventual Consistency Pattern

Sharding Pattern