What is the difference between eventual and strong consistency?

Strong consistency guarantees every read returns the most recent write, so the system behaves as if there were one copy. Eventual consistency only guarantees replicas converge at some unspecified later point, so a read can return older data with no warning that it did.

What is read-your-own-writes consistency?

A guarantee that a user always sees their own changes, even if other users see them later. It is the single most valuable weak guarantee, because almost every "the site is broken" report from eventual consistency is really a user not seeing something they just did.

How long is "eventually"?

Unbounded in theory; in practice usually milliseconds, occasionally minutes when a replica falls behind under load or during maintenance. The danger is that it is not a number you can rely on, so code must be correct for any lag, not the typical one.

Is eventual consistency bad?

No — it is what makes systems fast and available across regions. It is bad only when applied to data where a stale read causes harm, such as balances, inventory or permissions. The mistake is choosing one model for an entire system rather than per operation.

Discovery Distributed Systems 4 min read · Updated 6 Aug 2026

Eventual vs Strong Consistency Explained

intermediate distributed-systemsconsistencyreplication

Two replicas of the same data. Someone writes to one. What does the other one return, and when?

Strong consistency answers: the new value, always, from the moment the write is acknowledged. The system behaves as if there were exactly one copy, no matter how many there really are.

Eventual consistency answers: the old value, for a while. The replicas converge eventually, which is a real guarantee but not a bounded one.

The bug users actually report

Nobody files a ticket saying “your replicas have diverged”. They say “I updated my profile and it didn’t save” — and then it appears when they refresh a minute later.

What happened: the write went to the primary, the subsequent read was served by a replica that had not caught up, and the user saw their own change vanish. The system was working exactly as designed, and the user’s trust in it took the damage anyway.

That symptom has a specific name and a specific fix, and it is not “switch to strong consistency”.

The guarantees between the two extremes

Consistency is a spectrum, not a switch. In roughly increasing strength:

Read-your-own-writes. A user always sees their own changes. Others may lag. Implementation is usually mundane: after a write, route that user’s reads to the primary for a few seconds, or pin them to the replica that has caught up.

Monotonic reads. Time never runs backwards for a given user. Without this, a user hitting two replicas alternately can see a comment appear, vanish, and reappear — which reads as a haunted website. Sticky sessions per replica fix it.

Causal consistency. Operations that depend on each other are seen in order by everyone. A reply never appears before the comment it replies to. Stronger, more machinery, and usually what “we need consistency” actually means when someone says it about a social feature.

Strong consistency. Everyone sees everything immediately, in one order. Full correctness, paid for in coordination.

What strong consistency costs

Coordination. Before acknowledging a write, enough replicas must agree — and “enough” means waiting for the slowest of a quorum.

Within one data centre that is sub-millisecond and rarely matters. Across regions it is tens to hundreds of milliseconds on every single write, because the speed of light is not negotiable. A quorum spanning Mumbai and Virginia pays that round trip regardless of how good your code is.

There is an availability cost too: if a quorum is unreachable, a strongly consistent system must refuse the write rather than accept something it cannot confirm. That is the CAP trade-off arriving in production.

Where lag comes from

Replication lag is not constant, and the times it spikes are the times you least want it to:

Write bursts. The primary accepts faster than replicas apply.
Long transactions. A big migration or bulk update ships as one lump.
Replica load. A replica serving heavy analytics applies changes slower.
Maintenance. A replica rejoining after a restart replays from behind.

So the honest planning assumption is that lag is usually milliseconds and occasionally minutes. Code that is correct only under typical lag is code that breaks during incidents — which is precisely when its behaviour matters most.

Monitor lag as a first-class metric, and make routing decisions from it: a replica beyond your threshold should stop receiving reads that care.

Choosing, per operation

The productive question is never “is this system consistent” — it is what breaks if this particular read is five seconds stale?

Operation	Stale is…	Choose
Account balance before a transfer	dangerous	strong
Remaining stock on the last item	dangerous	strong
Permission or role check	dangerous	strong
A user’s own profile after editing	confusing	read-your-own-writes
Comment thread ordering	confusing	causal
Follower count, view count	fine	eventual
Search results, recommendations	fine	eventual
Product description text	fine	eventual

Most rows in most applications are the bottom half. Serving them from replicas is what makes a system fast and cheap; the discipline is knowing exactly which rows are not.

What you have actually chosen

Not a database setting. You have chosen how long your system is allowed to disagree with itself, and who is allowed to notice.

Eventual consistency says disagreement is temporary and harmless here. Strong consistency says it is never acceptable here, and buys that with latency and with failures during partitions. The systems that work well are the ones where somebody wrote down which data is which — rather than the ones that picked a single answer and applied it to everything.

Quick answers

What is the difference between eventual and strong consistency?: Strong consistency guarantees every read returns the most recent write, so the system behaves as if there were one copy. Eventual consistency only guarantees replicas converge at some unspecified later point, so a read can return older data with no warning that it did.
What is read-your-own-writes consistency?: A guarantee that a user always sees their own changes, even if other users see them later. It is the single most valuable weak guarantee, because almost every "the site is broken" report from eventual consistency is really a user not seeing something they just did.
How long is "eventually"?: Unbounded in theory; in practice usually milliseconds, occasionally minutes when a replica falls behind under load or during maintenance. The danger is that it is not a number you can rely on, so code must be correct for any lag, not the typical one.
Is eventual consistency bad?: No — it is what makes systems fast and available across regions. It is bad only when applied to data where a stale read causes harm, such as balances, inventory or permissions. The mistake is choosing one model for an entire system rather than per operation.