Understanding Eventual Consistency

Eventual consistency is a consistency model that guarantees all replicas will converge to the same value given enough time.

ACID vs BASE

ACID (Strong Consistency):
  Atomic, Consistent, Isolated, Durable
  → SQL databases, financial systems

BASE (Eventual Consistency):
  Basically Available, Soft state, Eventually consistent
  → Cassandra, DynamoDB, DNS

What Eventual Consistency Means

Write to Replica 1:
  user:123 = { balance: 100 }

Read from Replica 2 immediately:
  user:123 = { balance: 80 }  ← Stale!

After replication (seconds later):
  Replica 2: user:123 = { balance: 100 } ← Converged

Consistency Guarantees (Weak to Strong)

1. Eventual Consistency
   → All replicas converge eventually

2. Monotonic Reads
   → Once you read value V, never see older value

3. Read-Your-Writes
   → After writing, you always see your write

4. Monotonic Writes
   → Writes from one client applied in order

5. Causal Consistency
   → Causally related operations seen in order

6. Strong Consistency
   → All reads see latest write

Read-Your-Writes Pattern

User posts comment → Write to primary
User refreshes page → Read might hit replica

Solution:
  Track write timestamp in client session
  If read request within 1 min of write:
    → Route to primary
  Else:
    → Route to replica

Vector Clocks

Track causality in distributed system:

VC = { NodeA: 2, NodeB: 1 }
Meaning: A has sent 2 messages, B has sent 1

Compare: VC1 > VC2 if all components of VC1 ≥ VC2
Conflict: Neither VC1 > VC2 nor VC2 > VC1 → Concurrent writes

When Eventual Consistency is Acceptable

OK: Social media likes, view counts, DNS, caches
NOT OK: Bank transfers, inventory deduction, medical records

Conclusion

Eventual consistency enables massive scale and availability. The key is understanding which operations can tolerate staleness and designing compensating mechanisms for those that cannot.