Strong Consistency vs Eventual Consistency: What is the Difference?
Compare strong consistency and eventual consistency, their trade-offs under CAP theorem, and when to choose each in system design.
Expected Interview Answer
Strong consistency guarantees that any read immediately after a write returns that write's value everywhere, while eventual consistency allows reads to briefly return stale values on some replicas after a write, converging only after propagation completes.
Strong consistency typically requires coordination — a write is not acknowledged until it is durable on a quorum or all replicas, and reads may need to check with the same quorum, which adds latency and can reduce availability during network partitions (per the CAP theorem, strong consistency is usually paired with lower availability under partition). Eventual consistency instead acknowledges a write quickly on one node and lets replication catch up asynchronously, favoring low latency and high availability at the cost of temporary staleness. The right choice depends on the workload: financial balances and inventory counts often need strong consistency to avoid overselling or double-spending, while social media likes, view counts, or product catalogs can tolerate eventual consistency for better performance at scale.
- Strong consistency: correctness-critical reads always see the latest write
- Eventual consistency: lower latency and higher availability at scale
- Choosing per-workload avoids over-engineering either extreme
- Many systems offer tunable consistency (e.g. per-query quorum settings)
AI Mentor Explanation
Think of the third umpire's decision on a run-out: the on-field umpire will not raise the finger until the official review is fully confirmed and broadcast to everyone simultaneously — that is strong consistency, everyone sees the same ruling at the same instant. Compare that to a fan following the score via a delayed radio broadcast, who might hear the previous ball's result while the stadium has already moved on; that lag-then-catch-up is eventual consistency. A database choosing strong consistency waits for full confirmation before any read is answered; eventual consistency lets reads proceed immediately and catch up later.
Step-by-Step Explanation
Step 1
Identify the correctness requirement
Determine whether the data (e.g. balances, inventory) must never be read as stale, or whether brief staleness is acceptable.
Step 2
Pick the consistency model
Choose strong consistency (quorum/leader-based writes and reads) for correctness-critical data, or eventual consistency for scale and availability.
Step 3
Configure replication accordingly
Strong consistency often uses synchronous replication or leader reads; eventual consistency uses asynchronous replication.
Step 4
Handle the trade-off explicitly
Strong consistency accepts higher latency/lower availability under partition; eventual consistency accepts temporary staleness for speed.
What Interviewer Expects
- Clear, correct definitions of both consistency models
- Concrete example of when each model is the right choice
- Mention of the CAP theorem trade-off (consistency vs availability under partition)
- Awareness that many real systems offer tunable consistency per operation
Common Mistakes
- Claiming one model is always better than the other in every case
- Not connecting the choice to the CAP theorem or to latency/availability trade-offs
- Giving an example that does not actually illustrate the difference
- Confusing eventual consistency with an unreliable or broken system
Best Answer (HR Friendly)
“Strong consistency means every read always sees the latest write immediately, everywhere, which usually costs more latency. Eventual consistency means reads might briefly show old data on some servers right after a write, but everything catches up shortly after, which is faster and more available. You pick strong consistency for things like account balances, and eventual consistency for things like view counts where a short delay does not matter.”
Code Example
-- STRONG CONSISTENCY: read from the leader/quorum to guarantee latest value
BEGIN;
SELECT balance FROM Accounts WHERE account_id = 1 FOR UPDATE; -- reads latest, locks row
UPDATE Accounts SET balance = balance - 100 WHERE account_id = 1;
COMMIT;
-- EVENTUAL CONSISTENCY: read from any nearby replica, may be slightly stale
SELECT view_count FROM Posts WHERE post_id = 42;
-- acceptable if this replica is a few seconds behind the primaryFollow-up Questions
- How does the CAP theorem explain the trade-off between these two models?
- What is a quorum read/write and how does it enable tunable consistency?
- Can a single system offer strong consistency for some operations and eventual for others?
- What is causal consistency and how does it sit between the two?
MCQ Practice
1. Which statement best describes strong consistency?
Strong consistency guarantees that once a write completes, every subsequent read sees it, with no stale results.
2. Which workload is the best fit for eventual consistency?
A like counter tolerates brief staleness with no real harm, making it a good candidate for eventual consistency and lower latency.
3. According to the CAP theorem, what does choosing strong consistency typically cost during a network partition?
Under a partition, a strongly consistent system must sacrifice availability for some requests to avoid returning inconsistent data.
Flash Cards
Strong consistency in one line? — Every read after a write returns the latest value everywhere, immediately.
Eventual consistency in one line? — Reads may briefly return stale values, but all replicas converge once propagation completes.
When to choose strong consistency? — For correctness-critical data like balances, inventory counts, and seat allocation.
When to choose eventual consistency? — For high-scale, latency-sensitive data like view counts, likes, or non-critical caches.