Strong vs Eventual Consistency

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

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

Practical Implementation for .NET Developers

In a .NET application, you would typically implement this pattern using the following approach:

ASP.NET Core setup: Create a service class that encapsulates the logic, register it with dependency injection, and inject it into your controllers or minimal API endpoints. The built-in DI container handles lifecycle management.

Entity Framework Core: For database interactions, EF Core provides the ORM layer. Use migrations for schema management and raw SQL for performance-critical queries. Consider Dapper for read-heavy paths where EF Core's overhead matters.

Azure integration: If deploying to Azure, leverage managed services — Azure Cache for Redis, Azure SQL, Azure Service Bus, Azure Cosmos DB. These eliminate operational overhead and provide built-in monitoring through Application Insights.

Testing: Use xUnit with Testcontainers for integration tests that spin up real databases in Docker. Mock external dependencies with NSubstitute. The WebApplicationFactory class lets you test your entire HTTP pipeline in-process.

Monitoring: Add Application Insights telemetry to track request latency, dependency calls, and custom metrics. Use structured logging with Serilog to make production debugging possible:

Log.Information("Processing order {OrderId} for {CustomerId}", orderId, customerId);

This gives you searchable, structured logs in Azure Monitor or Seq.

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:

1. What is the cost of stale data? Financial loss → strong. User inconvenience → eventual.
2. What latency is acceptable? Strong consistency adds latency (consensus protocol). Can you afford it?
3. 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.