Eventual Consistency

Eventual consistency means all nodes will eventually have the same data.

Eventual Consistency Explained

Write: Client A writes X = 1 to Node 1

Immediately:
Node 1: X = 1 ✓
Node 2: X = 0 (stale)
Node 3: X = 0 (stale)

After propagation:
Node 1: X = 1 ✓
Node 2: X = 1 ✓
Node 3: X = 1 ✓

All nodes converge to same value

Eventual vs Strong Consistency

Aspect	Eventual	Strong
Read after write	May be stale	Always current
Performance	Faster	Slower
Availability	Higher	Lower
Complexity	Simpler	More complex

How Eventual Consistency Works

1. Write to one node
2. Node acknowledges immediately
3. Background replication to other nodes
4. All nodes eventually have same data

Propagation methods:
- Gossip protocol
- Anti-entropy
- Read repair

Gossip Protocol

Node A: "I have X = 1"
Node B: "Thanks, I have X = 0"
Node A: "Here's X = 1"
Node B: "Updated to X = 1"

Eventually all nodes have X = 1

Eventual Consistency Guarantees

With Eventual Consistency:
✓ All nodes converge
✓ High availability
✓ Low latency
✓ Simple implementation

Without Eventual Consistency:
✗ May read stale data temporarily
✗ Conflicts possible
✗ Application must handle

When Eventual Consistency is OK

Good for:
- Social media feeds
- Analytics
- Caching
- DNS
- User preferences
- Shopping carts

Not good for:
- Financial transactions
- Inventory management
- User authentication
- Critical data

Eventual consistency is appropriate when availability and performance are prioritized.

Use Cases

1. Social Media
   - Feed updates
   - Like counts
   - Follower lists
   
   User posts → Immediate post visible to poster
   → Eventually visible to all followers

2. E-commerce
   - Product views
   - Review counts
   - Recommendation data
   
   Show approximate data immediately
   → Update as data propagates

3. Analytics
   - Event logging
   - Metrics aggregation
   - Reporting data
   
   Log events immediately
   → Aggregate eventually

4. Caching
   - Session data
   - API responses
   - User preferences
   
   Cache invalidation
   → Eventually consistent with source

Decision Framework

Use Eventual Consistency when:
✓ Can tolerate stale data
✓ High availability needed
✓ Performance critical
✓ Data not critical
✓ Application can handle

Use Strong Consistency when:
✗ Data accuracy critical
✗ Financial operations
✗ User expects current data
✗ Cannot tolerate stale reads

Eventual Consistency Patterns

1. Read-Through Cache
   - Read from cache
   - Cache miss → read from DB
   - Update cache
   - Eventually consistent

2. Write-Behind
   - Write to cache immediately
   - Async write to DB
   - Eventually consistent

3. Event Sourcing
   - Events stored immutably
   - Projections built eventually
   - Eventually consistent views

Eventual Consistency Best Practices

1. Design for staleness: Don't assume data is current
2. Use TTLs: Auto-expire stale data
3. Monitor convergence: Track time to consistency
4. Provide fallbacks: Handle stale data gracefully
5. Document staleness: Users should know data may be stale

When concurrent writes conflict, you need strategies to resolve them.

Conflict Types

1. Write-Write Conflict
   T1: Write X = 1
   T2: Write X = 2
   Which value wins?

2. Delete-Insert Conflict
   T1: Delete row
   T2: Insert row
   Result?

3. Concurrent Updates
   T1: Update X field
   T2: Update Y field
   Both valid, how to merge?

Conflict Resolution Strategies

1. Last-Write-Wins (LWW)
   - Timestamp-based
   - Most recent write wins
   - Simple but may lose data

2. Merge
   - Combine changes
   - Application-specific logic
   - Preserves all changes

3. Reject
   - Reject conflicting writes
   - Require user intervention
   - Ensures consistency

4. CRDTs
   - Conflict-free Replicated Data Types
   - Automatic merge
   - No conflicts possible

Last-Write-Wins

T1: Write X = 1 at T=100
T2: Write X = 2 at T=101

LWW: T2 wins (later timestamp)
Result: X = 2

Problem: T1's write lost silently

Merge Strategy

T1: Update address = "123 Main St"
T2: Update phone = "555-1234"

Merge: Both changes applied
Result: address = "123 Main St", phone = "555-1234"

Requires application logic to merge

CRDTs (Conflict-free Replicated Data Types)

CRDTs are data structures that:
- Can be updated concurrently
- Always converge to same state
- No conflicts possible

Examples:
- G-Counter: Grow-only counter
- PN-Counter: Positive-Negative counter
- G-Set: Grow-only set
- OR-Set: Observed-Remove set

CRDT Example

G-Counter (grow-only counter):

Node A: {A: 3, B: 0}
Node B: {A: 0, B: 5}

Increment A on Node A: {A: 4, B: 0}
Increment B on Node B: {A: 0, B: 6}

Merge: {A: 4, B: 6}
Total: 10

No conflicts possible!

Conflict Resolution Best Practices

1. Choose based on use case: LWW for simple, CRDTs for complex
2. Design for conflicts: Assume they will happen
3. Log conflicts: Track for debugging
4. Provide resolution UI: Let users resolve when needed
5. Test under load: Verify conflict handling