What is Eventual Consistency in Databases?
Understand eventual consistency, why replicas can briefly diverge, and how systems like Cassandra and DynamoDB resolve conflicts.
Expected Interview Answer
Eventual consistency is a consistency model where, after writes stop arriving, all replicas of a piece of data are guaranteed to converge to the same value eventually, but reads immediately after a write may temporarily return stale or differing results from different replicas.
Instead of blocking a write until every replica confirms it (as strong consistency requires), an eventually consistent system accepts the write on one node and propagates it to others asynchronously in the background, often via gossip protocols, replication logs, or anti-entropy processes. This trades a temporary window of staleness for lower latency and higher availability, which is why systems like DNS, many NoSQL databases (Cassandra, DynamoDB), and CDNs use it by default. Applications built on eventual consistency must be designed to tolerate stale reads, using techniques like read-your-writes guarantees, versioning, or conflict resolution (e.g. last-write-wins or vector clocks) for concurrent updates.
- Lower write latency since it does not wait for all replicas
- Higher availability during network partitions
- Scales well across geographically distributed replicas
- Common building block for highly available NoSQL systems
AI Mentor Explanation
Think of a stadium's live score being updated on the main scoreboard instantly, while several mobile apps showing the same score sync from it every few seconds rather than in real time. For a brief window after a boundary is hit, the stadium screen shows the new total while an app on someone's phone still shows the old one, but within seconds every app catches up and matches. Eventual consistency works the same way: a write lands first on one node, and every replica converges to the same value shortly after, without blocking on instant agreement.
Step-by-Step Explanation
Step 1
Accept the write on one node
A write is applied and acknowledged on the node (or a small quorum) that first received it, without waiting for all replicas.
Step 2
Propagate asynchronously
The change is replicated to other nodes in the background via replication logs, gossip protocols, or anti-entropy processes.
Step 3
Tolerate temporary divergence
During propagation, different nodes may return different values for the same key if read concurrently.
Step 4
Converge once propagation completes
After enough time with no new writes, all replicas hold the same value, resolving any conflicts via rules like last-write-wins or vector clocks.
What Interviewer Expects
- Clear definition distinguishing eventual consistency from strong consistency
- A concrete example of stale reads across replicas
- Awareness of conflict-resolution strategies (last-write-wins, vector clocks)
- Understanding of the availability/latency trade-off it provides
Common Mistakes
- Claiming eventually consistent systems never converge or guarantee anything
- Confusing eventual consistency with no consistency at all
- Not mentioning real systems (Cassandra, DynamoDB, DNS) that use this model
- Failing to explain how conflicting concurrent writes get resolved
Best Answer (HR Friendly)
“Eventual consistency means that when data is updated, different copies of that data across servers might briefly show different values, but they are guaranteed to catch up and match each other once the update finishes spreading. It is a trade-off many large-scale systems make to stay fast and available instead of waiting for every server to agree instantly.”
Code Example
-- Write accepted on the local/nearest replica, acknowledged immediately
INSERT INTO UserProfile (user_id, display_name, version, updated_at)
VALUES (101, 'New Name', 7, NOW());
-- A read against a DIFFERENT replica moments later may still show the old value
SELECT display_name, version FROM UserProfile WHERE user_id = 101;
-- may temporarily return ('Old Name', 6) until replication catches up
-- Conflict resolution example: last-write-wins by comparing version/timestamp
-- during replication, the replica keeps the row with the higher version number
-- so all replicas converge to ('New Name', 7) once propagation completesFollow-up Questions
- What is the difference between eventual consistency and read-your-writes consistency?
- How do vector clocks help resolve conflicting concurrent writes?
- How does the CAP theorem relate to choosing eventual consistency?
- Name a database that defaults to eventual consistency and one that defaults to strong consistency.
MCQ Practice
1. What does eventual consistency guarantee?
Eventual consistency allows temporary divergence between replicas but guarantees they converge once propagation finishes.
2. Why might two replicas return different values for the same key immediately after a write?
The write lands on one node first and is propagated asynchronously, so other replicas may briefly lag behind.
3. Which technique is commonly used to resolve conflicting concurrent writes in eventually consistent systems?
Eventually consistent systems often use last-write-wins timestamps or vector clocks to reconcile concurrent conflicting updates.
Flash Cards
What is eventual consistency? — A model where replicas may temporarily diverge after a write but are guaranteed to converge once propagation completes.
Name two systems that use eventual consistency. — Cassandra and DynamoDB (also DNS and many CDNs).
How are write conflicts resolved? — Commonly via last-write-wins timestamps or vector clocks during replication/anti-entropy.
Main trade-off of eventual consistency? — Lower latency and higher availability in exchange for temporarily stale reads.