Strong vs Eventual Consistency

Consistency in distributed systems is about a deceptively simple question: after you write some data, when is it guaranteed to be visible to readers?

In a single-server world, this is trivial — you write something, anyone who reads immediately after sees it. Done. But once your data lives on multiple nodes, replicated across different machines or even different data centers, the answer gets complicated. How do you handle the gap between when data is written to one node and when it propagates to all others?

The two ends of the spectrum are strong consistency and eventual consistency.

Strong Consistency: What You See Is What Exists

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Strong consistency guarantees that after a write completes, every subsequent read from any node sees that write. The implementation requires coordination: the primary node receives the write and synchronously replicates it to a quorum of replicas before returning success to the client. Only after enough replicas acknowledge can the write be confirmed. This means the client waits for the slowest replica in the quorum — and if replicas are geographically distributed, you're waiting for network round-trips across hundreds of milliseconds. The benefit is an unambiguous guarantee: no reader ever sees stale data. This is essential for financial systems (bank balances must be exact), inventory management (you can't sell the same "last item" twice), and distributed coordination (locks and leader election require everyone to agree on the current state).

1 / 10.5×1×2×3×Playground

Strong consistency — quorum write, all replicas sync before ack

With strong consistency, after a write completes, every subsequent read — from any node, by any client — sees that write. There is a single, linear view of history. No client ever reads stale data.

Think of a bank account. You transfer $500 to a friend. The moment that transfer is confirmed, your balance shows $500 less. If you check your balance from your phone and your laptop at the same time, both show the same number. This is non-negotiable. Nobody wants a financial system where one device shows $1000 and another shows $500 simultaneously.

Strong consistency feels like the obvious choice. And for many domains — financial transactions, inventory management, distributed locks — it absolutely is.

The Performance Cost

Strong consistency has a real price: coordination between nodes takes time.

To guarantee that every reader sees the latest write, the system has to synchronize writes across replicas before acknowledging success. In practice, this means:

• The leader node receives the write
• It waits for a quorum of replicas to acknowledge the write
• Only then does it return success to the client

That coordination adds latency. The more geographically distributed your replicas, the more latency (speed of light is not negotiable). This is why strongly consistent systems struggle across continents — the round-trip time to synchronize replicas in multiple regions might be 100ms+.

Strongly consistent systems also reduce availability. During a network partition, a CP system (in CAP theorem terms) will refuse to serve reads or writes rather than risk returning inconsistent data.

Eventual Consistency: It'll Get There

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

Eventual consistency makes a weaker but still useful guarantee: if no new updates are made, all replicas will converge to the same value — eventually. Writes succeed immediately on the primary without waiting for replica acknowledgment. Replication happens asynchronously in the background. In the window between write and replication, different readers may see different values. For a social media "like" counter, this is completely acceptable: seeing 1,203 instead of 1,204 for a few seconds causes no harm and the user can't tell the difference. The payoff is significant: writes are faster (no quorum wait), reads can be served from the nearest replica (no routing to primary), and the system remains available even during network partitions. Amazon's Dynamo shopping cart uses eventual consistency — they would rather show a slightly stale cart than have the cart service be unavailable. The design principle: reserve strong consistency for data where stale reads cause real harm; use eventual consistency everywhere else.

1 / 10.5×1×2×3×Playground

Eventual consistency — write fast, replicas converge async

Eventual consistency makes a weaker guarantee: if no new updates are made to a piece of data, eventually all replicas will converge to the same value. But in the meantime, different replicas might return different values.

Think of the "like" count on a social media post. If a post gets liked, you might briefly see "1,204 likes" while your friend sees "1,203 likes." A second later, both of you see "1,204 likes." The system converged. You both saw stale data for a moment, but did it matter? Not even slightly.

Eventual consistency trades correctness guarantees for performance and availability:

• Writes can succeed immediately on one node without waiting for all replicas
• Reads can be served from the nearest replica
• The system stays available even during network partitions (AP in CAP terms)
• Latency is lower because there's no synchronization overhead

Real Examples

Amazon's Dynamo paper (2007) is the foundational text on eventual consistency. It describes how Amazon's shopping cart uses eventually consistent storage — they would rather show you a slightly stale cart than have the cart service be unavailable. A missed cart item is recoverable; downtime is not.

Read-Your-Writes: A Useful Middle Ground

In practice, strict strong consistency is often overkill, but pure eventual consistency can feel broken to users. There's a middle ground that solves the most common user-facing problem: read-your-writes consistency (also called read-after-write consistency).

The guarantee: after you write data, you will always see your own write — even if other users might briefly see stale data.

This matters for user experience. If you update your profile picture and immediately navigate away and back, you expect to see your new picture. If you see the old one, something feels broken. Other users seeing your old picture for a few seconds is barely noticeable.

How is this implemented? A few common approaches:

• Read from the primary/leader — for any data the current user just modified, route reads to the primary node that accepted the write
• Read your replica — after a write, pin subsequent reads from that user to the same replica until replication catches up
• Version tracking — the client tracks the version of its last write; reads that don't meet that version are retried or routed to primary

This is what most "consistent" consumer apps actually implement. Facebook, Instagram, Twitter — they're not strongly consistent globally, but they do ensure you see your own updates immediately.

Choosing Your Model

Choose strong consistency when:

• Correctness is more important than latency (financial systems, medical records)
• Data represents a shared resource that can't be double-used (inventory, seats)
• You're implementing distributed coordination (locks, leader election)

Choose eventual consistency when:

• Scale and availability matter more than perfect freshness
• The domain tolerates slight staleness (social feeds, analytics, DNS)
• You're geo-distributing across regions (synchronization lag makes strong consistency impractical)

Consider read-your-writes as a default for most user-facing features — it delivers a consistent experience to each user while still giving you the performance benefits of replication.

The trap to avoid is assuming strong consistency everywhere "to be safe." Strong consistency is expensive and limits your ability to scale horizontally and survive network failures. Most of your data doesn't need it. Reserve it for the parts that do.

Summary

Strong consistency guarantees that after a write, every subsequent read from any node sees that write. It's essential for financial data and shared resources but comes with latency overhead and reduced availability. Eventual consistency allows replicas to temporarily diverge and converge over time — enabling lower latency, higher availability, and global distribution at the cost of brief staleness. Read-your-writes consistency is a practical middle ground: each user sees their own updates immediately while other users might briefly see stale data. Most large-scale systems use eventual consistency by default and apply strong consistency only where correctness is truly non-negotiable.