Should every workload use strong consistency now that distributed SQL has matured? Not necessarily. Different applications tolerate different failure modes. Our new article explores where strong consistency pays off, where eventual consistency still wins, and how AI changes the equation.
Two shoppers click Buy on the last item in stock at the same instant. Does the system take both orders? Or does the second shopper immediately see the item’s gone?
That’s the difference between strong and eventual consistency. For over a decade, the industry defaulted to eventual consistency because strong consistency simply couldn’t scale. In 2026, that assumption deserves another look. Distributed SQL has made strong consistency practical at scale, and AI pipelines have turned stale reads into production bugs you’ll actually care about.
Why the tradeoff changed in 2026
Around 2010s, the rules were simple: if you wanted to scale, you accepted eventual consistency. Today that tradeoff is far less rigid.
Distributed SQL databases can now give you strongly consistent reads across regions without giving up the scalability enterprises expect – Google Spanner and CockroachDB brought this architecture into the mainstream, TigerBeetle’s joined them more recently, and the list of workloads that genuinely need eventual consistency is shrinking faster than most teams want to admit.
In modern systems, it usually belongs at the storage or caching layer, not in the service or API layer. Treating it as a default for every workload is a mistake.
AI reopened the question from the other side. Retrieval pipelines and AI agents routinely write data and read it back seconds, or even milliseconds, later. That might be a newly generated embedding or stored memory. It might be the result of a tool invocation. On an eventually consistent system, the write may not be visible yet. A one-second delay you wouldn’t notice in a social media feed (where it probably doesn’t matter) suddenly becomes an AI agent that’s making decisions on incomplete information.
Storage is moving the same way. Amazon S3 moved to strong read-after-write consistency for all objects in 2020 (after years of eventual consistency) and added conditional writes in 2024. Stronger consistency guarantees are becoming the default wherever they solve real operational problems. You shouldn’t inherit eventual consistency just because it was yesterday’s best practice.
Figure 1. Comparison of strong and eventual consistency models.
What strong and eventual promise
Strong consistency (its formal name is linearizability) means that once a write’s acknowledged, every later read from any node returns that value. There are no stale reads. The system behaves as if there’s a single copy of the data even when three copies sit on three different machines.
Eventual consistency means writes are accepted immediately and copied out in the background. Replicas can disagree for a short window, but they converge once writes settle and replication keeps running. Eventual doesn’t mean wrong forever; it means briefly stale, and the length of that window is exactly what you’re trading on. You accept that tradeoff in exchange for lower latency and higher availability.
Weak consistency is the third model. It provides no guarantee that you’ll read the latest value at all. That’s perfectly acceptable for multiplayer games or live leaderboards where responsiveness matters more than precision. Eventual consistency sits between these two extremes. It offers predictable convergence without the strict guarantees of linearizability. Amazon’s product catalog illustrates eventual consistency well. A price update or review count may take a short time to appear everywhere, and customers rarely notice. The checkout and payment systems behind that same website are built differently because they can’t tolerate stale reads. Most large-scale systems naturally split workloads this way. None of these models is universally “better.” They just optimize for different balances. If you understand that, you can pick the right guarantee.
Enough theory.
On to the CAP theorem.
| Model |
Reads the latest write? |
Latency |
Availability under failure |
Typical fit |
| Strong |
Always |
Higher |
Lower, may go read-only |
Ledgers, inventory, locks |
| Eventual |
After a short delay |
Lower |
Higher |
Feeds, caches, analytics |
| Weak |
Not guaranteed |
Lowest |
Highest |
Games, live dashboards |
The tradeoff you cannot escape
No distributed system can simultaneously guarantee strong consistency, high availability, and partition tolerance during a network partition. That’s the essence of the CAP theorem. When partitions occur, a strongly consistent system may reject reads or writes to preserve correctness. The exact behavior depends on its design.
An eventually consistent system can keep serving requests and reconcile replicas afterward. In practice, MongoDB and HBase generally favor consistency, while Cassandra and DynamoDB favor availability. That said, CAP is often oversimplified. Real network partitions are relatively uncommon, and the familiar “pick two” explanation hides the tradeoff you’ll notice every day: latency.
PACELC makes this explicit: if there’s a partition, you choose between availability and consistency, and else, during normal operation, you choose between latency and consistency.
That second half matters far more in day-to-day operations. Even on a perfectly healthy network, a strongly consistent read usually waits for a quorum response. Those additional milliseconds are the ongoing cost you’ll pay for stronger guarantees.
How the guarantee gets enforced
Two mechanisms do most of the work behind the scenes: quorum protocols at the database layer and replication underneath.
Strong consistency typically relies on quorums. If the read quorum plus the write quorum exceeds the total number of replicas, every read is guaranteed to overlap with the latest successful write. That overlap prevents stale reads.
Imagine three replicas. If the system requires acknowledgments from two replicas for every write and consults two replicas for every read, those groups must always share at least one node. That shared replica contains the newest committed value, so stale reads can’t happen. This overlap is the core idea behind quorum-based consistency.
Replication determines how writes reach those replicas, and two approaches dominate: synchronous and asynchronous. Synchronous replication waits until every required copy acknowledges the write before reporting success, which provides strong consistency, although write latency is limited by the slowest participating replica. Asynchronous replication acknowledges the write immediately and replicates it afterward, so your application sees lower latency, but a node failure before replication completes can still lose the most recent writes, and that’s the price you pay for speed. Consensus protocols like Paxos and Raft coordinate this process by ensuring every node agrees on the order of operations. The implementations differ, but the practical takeaway is simple: reaching agreement requires additional network round trips.
Where strong consistency is non-negotiable
Some workloads treat a stale read as a bug that costs money or breaks safety.
Financial transactions are the obvious example.
A balance that still appears positive after funds have been withdrawn is stale data escaping into production.
So is an oversold airline seat.
A customer charged twice is the same problem.
Imagine two customers buying the final copy of a book within milliseconds of each other. Without strong consistency, both purchases succeed. Your operations team’s got to issue refunds and sincere apologies.
A subtler failure mode shows up in read-modify-write workflows. Marc Brooker’s AWS example is the classic illustration: an application creates a resource and immediately reads it back. If that read reaches a lagging replica (maybe in a different availability zone), the database responds as though the resource never existed. From the application’s perspective, time’s just moved backward.
Teams often try masking this with retry loops and arbitrary sleep intervals. Those workarounds add latency. They’ll still fail if the resource’s been genuinely deleted instead of simply delayed.
That’s why banking platforms and inventory systems willingly pay the latency cost of strong consistency. It’s also why Google Spanner introduced TrueTime to provide external consistency across regions, and why AWS built Aurora DSQL around strongly consistent reads.
Where eventual consistency is the right call
Strong consistency isn’t the answer everywhere. For many workloads, eventual consistency remains the most practical choice.
Netflix serves viewing history and recommendations from eventually consistent Apache Cassandra clusters. Profile data lives there too. If the “Continue Watching” row updates a few seconds late, you won’t notice. DNS works the same way.
Record changes propagate gradually across the Internet, yet the entire ecosystem’s designed around that behavior. Content delivery networks such as Cloudflare and Akamai intentionally cache slightly stale content at the edge. Users benefit far more from fast responses than from perfectly fresh assets. Analytics and reporting platforms make similar tradeoffs. They’ll choose availability over reading the newest possible byte.
Cost’s also a factor. Amazon DynamoDB prices eventually consistent reads at roughly half the cost of strongly consistent reads. If you can tolerate a few seconds of staleness, you’ll pay significantly less.
Strong consistency pushes cost the other way. Synchronizing replicas requires extra consensus traffic and CPU time, and it’ll burn more cross-region bandwidth too. If every read uses strong consistency by default, infrastructure costs go up even when the application’s gaining little from the stronger guarantee.
That’s why most modern architectures mix both models. Use strong consistency where stale data creates correctness problems. Eventual consistency fits where responsiveness and availability matter more than reading the absolute latest value, or where cost’s the deciding factor. Amazon S3’s move to strong read-after-write consistency is a good example of this principle. The company strengthened consistency exactly where it eliminated a class of bugs developers repeatedly encountered. Other parts of the architecture stayed optimized for scale.
The storage layer already made this choice for you
Most discussions of consistency stop at the database. In practice, your consistency guarantee’s only as strong as the storage beneath it.
If the block layer loses the last acknowledged write after a node failure, the strong consistency you configured one layer above becomes a promise the infrastructure can’t keep.
The familiar read-replica race has a storage equivalent (and it’s just as painful). Asynchronous block replication acknowledges a write before the secondary copy exists, so during failover the application can suddenly see data that’s older than what it’s already committed.
This is where synchronous mirroring matters. StarWind VSAN protects acknowledged writes by mirroring every write between two storage nodes and confirming it only after both copies are safely committed. A two-node deployment using the Heartbeat failover strategy can provide high availability without a separate witness node; the footprint stays small.
For larger heterogeneous estates, DataCore SANsymphony applies the same synchronous mirroring across mixed arrays for tier-one block workloads.
In practice, the decision’s straightforward. Match the storage guarantee to the workload. There’s little value in synchronously mirroring data that’s read once every quarter, yet placing a financial ledger on an eventually consistent storage tier makes equally little sense.
What AI and agentic workloads change
AI’s changed consistency from a database setting into an infrastructure decision. Agent and retrieval workflows are fundamentally read-modify-write loops (they’re the same pattern at a different scale). They might generate an embedding, store a memory, or record a tool result. Whatever they write, they’ll often query it immediately. On an eventually consistent vector store, that write won’t be searchable yet.
The reason’s usually the index. Approximate nearest neighbor (ANN) indexes are rebuilt incrementally. A newly inserted vector can remain invisible to similarity search for seconds or even minutes, even though the underlying database already stores it and would return it through a direct lookup. For a chatbot summarizing last quarter’s reports, that delay rarely matters. An autonomous agent acting on a record it created moments earlier faces a correctness bug. These often slip through testing because quick demos rarely expose the timing window.
If you’re on the infrastructure team, this quickly becomes a placement question. Real-time inference and agent memory are increasingly deployed close to the compute layer. That might be on-premises. It might sit at the edge. Dedicated AI clusters are another common target. As a result, the consistency guarantees provided by the underlying storage directly affect application behavior.
That doesn’t mean every AI workload needs strong consistency. It means identifying the handful of operations where an agent can’t safely act on stale state. Let retrieval, analytics, and other latency-sensitive paths benefit from eventual consistency.
It isn’t always binary: tunable consistency
Consistency isn’t always an all-or-nothing switch. Apache Cassandra lets you choose a consistency level for each operation. A single-replica read minimizes latency. Quorum reads provide strong enough guarantees for many workloads. Full agreement across every replica delivers the strongest consistency, but you’ll pay with higher latency and reduced availability. That flexibility means the same application can require strong consistency during checkout while serving product pages with eventually consistent reads.
Between those two extremes sit several useful middle-ground guarantees. Read-your-writes consistency ensures you’ll see your own updates. Monotonic reads prevent a session from moving backward in time. They stop the system from returning older versions of data after newer ones have already been observed.
Causal consistency’s particularly useful for collaborative applications. It preserves the order of related operations: a reply never appears before the message it’s responding to. Messaging platforms and social networks benefit from this behavior without paying the cost of global coordination, which is why you’ll often see it in threaded comment systems and shared document editors.
In practice, very few distributed systems need one consistency model everywhere – the checkout flow and the analytics pipeline have utterly different requirements, and that’s fine. These days, databases let you pick the right guarantee per operation. Pick per operation. Don’t pick once for the whole stack.
Matching the guarantee by workload
The same tradeoffs hit differently depending on what you’re running. No surprise there. A retail warehouse and a cardiac monitor don’t share the same constraints.
Financial services and e-commerce
Checkout flows keep strong consistency on the transaction path. You can’t afford a double-charge because a replica lagged behind.
Media and healthcare
Archives hold petabytes of cold objects, and eventual consistency on an object tier is the sensible, low-cost choice. Nobody’s waiting on an MRI from 2019 to propagate instantly.
SaaS and content platforms
Run eventual on the read path and reserve strong guarantees for the few operations that guard money or identity – billing, access control, that sort of thing. Most reads don’t need the newest byte immediately.
AI platforms
Lean eventual for bulk retrieval and analytics, and keep strong consistency only where an agent acts on state it just wrote. That’s rarer than most AI marketing suggests – usually it’s limited to narrow update paths in most stacks. (Most of the time the model’s just reading stale training data and nobody cares.)
Multi-site retail
You can run a two-node, synchronously mirrored cluster at each location. Failover keeps critical local state available without forcing every transaction through a distant regional round trip. It’s slower, but the register stays up when the WAN hiccups.
How to choose
Start with one question for every operation: what happens if this read’s a few seconds stale? If the answer involves money or safety, strong consistency is usually the right choice – those are exactly the domains where a stale read turns into a real incident that’s hard to unwind. Where nobody would notice, eventual consistency will likely give you better performance at lower cost.
From there, the checklist is short. Think in terms of single operations, not whole applications, and apply strong consistency only where it delivers measurable value. Use tunable consistency levels if your database supports them. Also verify that your storage layer can actually uphold the guarantees your database claims, because a database configured for strong consistency is only as good as the replication running underneath it, and if that replication is asynchronous you’ve basically bought a label, not a guarantee. Then measure the latency. It matters. Even on a healthy network, strong consistency carries a cost, and that cost needs to be justified by the workload.
Most production systems end up somewhere in the middle. They combine strong and eventual consistency and apply each where it fits best. In 2026, more databases and storage platforms let you make that decision per operation instead of forcing one model across the entire system, which finally means you can tune by query rather than by cluster. That’s a welcome change – most teams have spent years over-provisioning clusters because vendors wouldn’t let them mix guarantees inside one deployment.
FAQ
Is eventual consistency just unreliable?
No. It’s briefly stale, then convergent. Give it a pause. Every replica ends up holding the same value, assuming the system’s healthy.
Can one system use both models?
Yes. Many engines expose tunable, per-operation consistency, so one application can run strong writes and eventual reads together. You don’t have to pick one model for the whole codebase.
How does storage replication affect my database’s consistency?
Directly. Asynchronous block replication can lose the last acknowledged writes on failover, and that quietly undercuts any strong guarantee you’ve configured above it, no matter what the database console claims. (Your database thinks it’s synchronous. The SAN underneath disagrees.)
Did distributed SQL make eventual consistency obsolete?
No. It made strong consistency cheaper at scale, but eventual still wins wherever latency and availability matter more than reading the newest byte, and that’s still most of the time.
from StarWind Blog https://ift.tt/jTh2VX5
via
IFTTT
