Eventual Consistency: The Optimist's Choice

The "BASE" of NoSQL

At the weak end of the spectrum is Eventual Consistency. This is the model used by many highly scalable NoSQL databases like Apache Cassandra, Amazon DynamoDB (in default configuration), and Amazon S3.

The guarantee is deliberately weak: if you stop making writes to the system, eventually all replicas will converge to the same state. The word "eventually" is intentionally vague — it could be milliseconds or seconds, depending on network conditions and replication lag.

While the system is actively receiving writes, different clients reading from different replicas may see different versions of the data simultaneously. There is no guarantee about which version you'll read, or that two consecutive reads will return the same value.

Why Use It?

Eventual consistency enables extremely high availability and low latency. Because writes don't need to wait for quorum coordination, they complete as fast as the local disk allows. Reads are served locally without cross-node coordination. This is why Cassandra can sustain millions of writes per second across a global cluster.

It embodies the BASE philosophy, framed as the pragmatic alternative to traditional database ACID properties:

• Basically Available: The system guarantees availability — it will answer requests even during partial failures.
• Soft state: The state of the system may change over time, even without new input, as replicas converge.
• Eventual consistency: The system will eventually become consistent once it stops receiving input.

When Is It Acceptable?

Eventual consistency is suitable for data where temporary divergence doesn't cause correctness problems:

• Social media "likes": It doesn't matter if one user sees 99 likes and another sees 100 for a few seconds.
• Product catalog prices: A brief stale price is tolerable; the checkout system can enforce the real price.
• DNS records: DNS is a classic example of eventual consistency — changes propagate globally over minutes to hours.

It is not suitable for data where correctness requires a single authoritative value: bank balances, inventory counts, distributed locks, or leader election.

Conflict Resolution

When two clients write to the same key on different replicas simultaneously, eventual consistency systems must have a strategy for resolving the conflict when replicas sync. Common approaches include:

• Last-Write-Wins (LWW): The write with the highest timestamp wins. Simple, but can silently discard data.
• Vector Clocks / Version Vectors: Track causality to detect true conflicts and surface them to the application for resolution.
• CRDTs (Conflict-free Replicated Data Types): Data structures mathematically designed to merge automatically without conflicts (covered in a separate topic).