How do you do multi‑DC conflict resolution (LWW vs CRDTs)?
Multi data center conflict resolution ensures that data replicas spread across regions remain consistent after concurrent writes. Two primary approaches, Last Write Wins (LWW) and Conflict Free Replicated Data Types (CRDTs), dominate this space. These models allow globally distributed systems like Amazon Dynamo, Cassandra, and Redis Active Active to converge safely without central coordination.
Why It Matters
When multiple regions accept local writes, conflicts are inevitable. A sound conflict resolution mechanism ensures that every replica eventually converges to the same state. Interviewers love this topic because it tests both theoretical understanding (causality, clocks, convergence) and practical reasoning (latency, correctness, trade-offs).
How It Works (Step by Step)
Step 1: Choose model per data shape
Use LWW when the most recent intent must override previous ones (e.g., user profile name or status).
Use CRDTs when multiple concurrent updates must be preserved (e.g., counters, likes, sets).
Step 2: Attach metadata
-
LWW: Append a timestamp or Hybrid Logical Clock to each write.
-
CRDTs: Add causal metadata (e.g., vector clocks, replica IDs) to encode intent.
Step 3: Define deterministic merge
-
LWW: Select the value with the latest timestamp or replica ID.
-
CRDTs: Merge states using associative, commutative, and idempotent operations.
Step 4: Write and replicate
Each region stamps writes locally and asynchronously replicates them. Peers merge incoming updates using the same rules.
Step 5: Handle deletes
Use tombstones in LWW to prevent deleted records from “resurrecting.”
In CRDTs, explicitly record removals (e.g., OR-Set keeps add/remove tags).
Step 6: Read repair
When replicas diverge, perform merges during reads. CRDTs are naturally safe for read repair since merges are idempotent.
Real-World Example
A global social platform stores user data in multiple regions:
-
Profile Bio → LWW field (last edit wins)
-
Followers Set → CRDT (OR-Set)
-
Likes Count → CRDT (PN-Counter) Each region handles writes independently and merges asynchronously, achieving eventual convergence with low latency and minimal user disruption.
Common Pitfalls
1. Lost intent in LWW LWW discards concurrent updates. Only one version survives, which can lose valuable user edits.
2. Clock skew Physical clocks can drift, making an older write appear “newer.” Prefer Hybrid Logical Clocks to maintain causal order.
3. Metadata explosion in CRDTs CRDTs maintain per-replica metadata, which can grow large over time. Compact tombstones after all replicas have acknowledged deletions.
4. Overuse of CRDTs Not every field requires a CRDT. Use them selectively to avoid complexity and memory overhead.
5. Misaligned semantics Combining LWW and CRDTs on the same entity without coordination can cause unpredictable merges.
Interview Tip
When asked about multi-DC conflict resolution in a system design interview, start by classifying the data. Suggest using LWW for single-value fields and CRDTs for counters or collections. Explain convergence, idempotence, and causality clearly because interviewers love hearing those key words.
Key Takeaways
-
Use LWW for simple fields; CRDTs for concurrent, additive data.
-
Always encode causal metadata for deterministic merges.
-
Compact tombstones to prevent storage bloat.
-
Use Hybrid Logical Clocks to reduce skew issues.
-
CRDTs guarantee convergence without coordination.
Table of Comparison
| Aspect | Last Write Wins (LWW) | CRDTs |
|---|---|---|
| Main Idea | Choose latest timestamp | Merge concurrent updates deterministically |
| Use Case | Single-value fields (bio, status) | Counters, sets, lists, collaborative docs |
| Conflict Handling | Loses concurrent updates | Preserves all concurrent updates |
| Clock Dependency | High (needs accurate timestamps) | Low (relies on internal causality) |
| Metadata Size | Small | Larger (per-replica tags, version vectors) |
| Complexity | Simple | Moderate to high |
| Delete Handling | Requires tombstones | Handled via remove tags |
| Latency | Very low | Low to moderate |
| Accuracy | May lose updates | Convergent by design |
| Typical Systems | DynamoDB, Cassandra (default) | Redis Active Active, Riak, CRDT-based systems |
FAQs
Q1. What is Last Write Wins in distributed databases?
It’s a conflict resolution strategy where the update with the latest timestamp wins, and all others are discarded.
Q2. How do CRDTs differ from LWW?
CRDTs merge concurrent updates mathematically, ensuring no data loss, while LWW overwrites all but one update.
Q3. When should I prefer CRDTs?
Use CRDTs for data like counters, sets, or lists where preserving all concurrent changes matters more than overwriting.
Q4. Do CRDTs need synchronized clocks?
No. CRDTs rely on internal causal metadata, not clock synchronization, to resolve order and intent.
Q5. How can I control CRDT storage overhead?
Implement compaction for tombstones, prune old metadata, and use delta-based replication.
Q6. What are common systems that use CRDTs?
Redis Active Active, Riak, and Akka Distributed Data implement CRDT-based conflict resolution.
Further Learning
To deeply understand replication patterns, consistency trade-offs, and convergence models, explore these expert-led courses on DesignGurus.io:
-
Grokking System Design Fundamentals – Learn the foundations of distributed systems and data consistency.
-
Grokking the System Design Interview – Master interview questions on replication, availability, and consistency with hands-on examples.
-
Grokking Scalable Systems for Interviews – Build intuition for region-level scaling, anti-entropy, and data reconciliation.
GET YOUR FREE
Coding Questions Catalog
$197

$78
$78