Eventual Consistency

Pradeep P
3 days ago
3 min read

Series: Modern System Design · Layer 4 — Data

Layer 4 · Post 5 of 11

← Previous: Optimistic vs Pessimistic Locking → Next: Distributed Transactions

Layer 4 — Data · Post 44 of 88

Eventual consistency accepts that replicas will disagree for a while, as long as they converge later if writes stop.

What you'll learn

What "eventual" actually guarantees (and what it does not)
Read-your-writes, stale caches, and why DynamoDB/S3/replicas look like this
The product questions you must answer before you say "eventual is fine"

The idea in one minute

ACID isolation is about concurrent transactions on one engine. Eventual consistency is about copies: replicas, caches, search indexes, another region.

If you stop writing, every copy eventually shows the same value. Until then, two reads can disagree.

Write "qty=4" to primary | +---- replica A (has qty=4) +---- replica B (still qty=5) <-- you just read this +---- Redis cache (qty=5) +---- Elasticsearch (qty=5)

No bug is required. Replication lag, async cache expiry, and an index pipeline are enough.

Why it matters

You left the world where one Postgres transaction was the whole truth. Read replicas, DynamoDB, Cassandra, S3, CloudFront, Kafka consumers, and CQRS read models (later in this layer) are eventually consistent unless you paid for something stronger.

Interviewers want to hear the user-visible consequence: "I just bought the last ticket and the list page still shows it." Then they want a mitigation: read-your-writes, session stickiness, version vectors, or "this screen is allowed to be 2 seconds behind."

How it works

A write lands on a leader or a quorum. Other copies catch up asynchronously (or with a weaker quorum). Conflicts, if two writers exist, need a rule: last-write-wins, vector clocks, CRDTs, or "you cannot write two places."

Useful stronger-than-chaos modes (still not full linearizability):

Read-your-writes: after you POST, the next GET for you should see it. Sticky sessions to the primary, or a "read from leader after write" flag.
Monotonic reads: you do not go backward in time on refresh.
Bounded staleness: Cosmos DB and some caches let you say "no older than N seconds."

Eventual consistency is a spectrum, not a shrug. Say how stale, for whom, and for which screen.

A simple example

You follow someone on a social graph stored in DynamoDB or Cassandra. The write hits one replica set. Your profile immediately shows "Following." Their follower count in another region increments a second later. That is eventual consistency as a product choice: follow buttons feel instant for the actor; global counts lag.

A bank ledger replica used to show "available balance" is a different product. There you often read the primary, or you show "pending" until the replica catches up.

Common mistakes

"Eventual" with no bound. If the consumer is down for an hour, the UI is an hour wrong. You need monitoring of lag, not a slogan.

Read-after-write on a replica. Signup creates a row on the primary; the next request load-balances to a replica that has not got it. The user thinks signup failed.

Treating cache TTL as a consistency model. A 5-minute TTL is a 5-minute lie. Fine for a banner. Not fine for "items left in cart."

Confusing this with ACID C. Eventual consistency is about copies. ACID C is about constraints in one commit.

How this shows up in real systems

DynamoDB, Cassandra, S3: designed around replication and (often) eventual or tunable consistency.
Postgres replicas / MySQL replicas: streaming replication lag is eventual consistency for readers.
Kafka + consumers: the log is ordered; the derived DB is behind.
CDN / Redis: the most common accidental eventual system in a design diagram.

Recap

Eventual consistency: copies converge later; reads may disagree now. Make the lag a product decision.
Use read-your-writes and lag alerts where users will notice.
Next: you still need one business action across two systems. That is a distributed transaction — and it will not feel like local ACID.