Strong vs Eventual Consistency
Strong consistency guarantees that after a write completes, all subsequent reads return the updated value.
Quick answer: Strong vs Eventual Consistency
Strong vs Eventual Consistency is covered here as a practical architecture tradeoff. Strong consistency guarantees that after a write completes, all subsequent reads return the updated value. Use it when comparing two architecture choices and explaining the operational cost, latency, reliability, and team-complexity impact of each option.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
Strong Consistency vs Eventual Consistency
Strong consistency guarantees that after a write completes, all subsequent reads return the updated value. Eventual consistency guarantees that all replicas will converge to the same value eventually, but reads may temporarily return stale data.
The Case for Strong Consistency
All nodes see the same data at the same time. Reads after writes always return the latest value.
What you gain: No stale reads. Simpler application logic. Required for financial data.
What you lose: Higher write latency (must wait for quorum). Lower availability during partitions. More expensive (synchronous replication).
Best when: Financial transactions (bank balances); Inventory management (preventing overselling); User authentication (password changes must be immediately visible); Any system where stale data causes real harm.
The Case for Eventual Consistency
Updates propagate asynchronously. Reads may return stale data temporarily. All replicas converge eventually.
What you gain: Lower latency. Higher availability. Better performance at global scale. Works well with AP systems.
What you lose: Stale reads possible. Application must handle conflicts. Harder to reason about.
Best when: Social media feeds (a slightly delayed post is acceptable); Product catalog (price changes can take seconds to propagate); Analytics and metrics (eventual accuracy is fine); DNS (changes propagate gradually).
Side-by-Side
| Strong Consistency | Eventual Consistency | |
|---|---|---|
| Strengths | No stale reads | Lower latency |
| Weakness | Higher write latency (must wait for quorum) | Stale reads possible |
| Use when | Financial transactions (bank balances) | Social media feeds (a slightly delayed post is acceptable) |
In the Real World
Google Spanner provides strong consistency globally using TrueTime — but at the cost of enormous infrastructure.
Amazon DynamoDB defaults to eventually consistent reads (cheaper, faster) with an option for strongly consistent reads.
Twitter uses eventual consistency for timelines — a new tweet may not appear in all followers' feeds instantly.
The Interview Take
The right choice depends entirely on the data. In the same system, use strong consistency for payments and eventual consistency for feeds. Never say 'I will use strong consistency for everything' — it shows you do not understand the tradeoff.
Source | System-Design-Overview
Real-World Decision Framework
Strong consistency guarantees that after a write, every subsequent read returns the updated value. Eventual consistency guarantees that if no new writes happen, all replicas will eventually converge to the same value — but reads during convergence may return stale data.
When Strong Consistency Is Required
Use strong consistency when incorrect data causes direct harm:
- Banking: A user's account balance must always reflect the most recent transaction. Showing $1,000 when $500 was just debited could allow overdrafts.
- Inventory management: If only 1 item remains, two users must not both see it as available and both purchase it.
- Distributed locks: When two services compete for a resource, the lock must be globally consistent.
- Configuration systems: When you deploy a feature flag change, all servers must read the updated value.
Technologies: Google Spanner (TrueTime), CockroachDB, etcd, ZooKeeper, single-leader databases with synchronous replication.
When Eventual Consistency Is Acceptable
Use eventual consistency when temporary staleness is tolerable and you need higher availability or performance:
- Social media feeds: If a user's post takes 2 seconds to appear in a follower's timeline, nobody notices.
- Product reviews: A new review appearing with a slight delay does not affect purchasing decisions.
- DNS: When you update a DNS record, it takes minutes to hours to propagate globally. This is eventual consistency by design.
- Shopping cart: Amazon's Dynamo paper showed that shopping carts can tolerate eventual consistency — items might briefly appear twice, but the checkout process reconciles.
Technologies: Amazon DynamoDB, Cassandra, Riak, CouchDB, DNS, CDN caches.
The Spectrum Between Strong and Eventual
In practice, there are intermediate consistency levels:
- Read-your-writes: You always see your own writes, but others may see stale data. Used by social media platforms.
- Causal consistency: If event A caused event B, everyone sees A before B. Sufficient for most collaborative applications.
- Session consistency: Within a single user session, reads are consistent. Across sessions, they may differ.
Interview Framework
When an interviewer asks about consistency, always tie it to the CAP theorem and specific requirements:
- What is the cost of stale data? Financial loss → strong. User inconvenience → eventual.
- What latency is acceptable? Strong consistency adds latency (consensus protocol). Can you afford it?
- How many replicas/regions? More regions → eventual is more practical. Single region → strong is feasible.
.NET Implementation
Strong: Use Azure Cosmos DB with ConsistencyLevel.Strong (single-region) or BoundedStaleness (multi-region). Eventual: Cosmos DB with ConsistencyLevel.Eventual or Session (most common). Use IDistributedCache with short TTLs for application-level eventual consistency.
Original DosiBridge notes for Strong vs Eventual Consistency
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Strong vs Eventual Consistency is to connect the concept to an asynchronous workflow where replay, ordering, and poison messages shape the architecture. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Decision Boundary: For Strong vs Eventual Consistency, decide the decision boundary before choosing tools; otherwise the design looks clean but fails when strong changes.
- Reversal Cost: For Strong vs Eventual Consistency, decide the reversal cost before choosing tools; otherwise the design looks clean but fails when vs changes.
- Operating Cost: For Strong vs Eventual Consistency, decide the operating cost before choosing tools; otherwise the design looks clean but fails when eventual changes.
- Team Maturity: For Strong vs Eventual Consistency, decide the team maturity before choosing tools; otherwise the design looks clean but fails when consistency changes.
- Growth Trigger: For Strong vs Eventual Consistency, decide the growth trigger before choosing tools; otherwise the design looks clean but fails when strong changes.
Production review question
If a team adopts Strong vs Eventual Consistency, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track strong-consistency health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Strong vs Eventual Consistency, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.