Strong vs Eventual Consistency: Choose the Right Guarantee
Prabhat
Sep 1, 20264 min read13 views
Day 11 helps you decide whether a read must reflect the latest completed write or may temporarily return an older value. This is a per-access-pattern decision, not a label you must apply to an entire product.
Advertisement
The mental model
Imagine the same record copied across multiple replicas.
With a strongly consistent read, a read reflects writes that completed before it began. The application can make a decision using the latest committed value exposed by that consistency guarantee.
With an eventually consistent read, a replica may briefly return an older value after a successful write. If new updates stop and replication succeeds, the replicas converge.
The important word is briefly. Eventual consistency does not mean “random forever.” It means your application must be designed for a period in which readers can observe different committed versions.
One flow, two guarantees
Step | Strong consistency | Eventual consistency |
|---|---|---|
A write succeeds | Later reads observe the latest completed write | Some replicas may still expose the previous value |
A read arrives | Coordination provides the stronger guarantee | A nearby or available replica may respond immediately |
During replication lag | Stale reads are prevented by the guarantee | Stale reads are possible and must be handled |
After updates stop | Replicas agree | Replicas converge after propagation completes |
Strong consistency can require more coordination, which may add latency or reduce availability during network failures. Eventual consistency can improve responsiveness and availability, but it transfers responsibility to the application: stale reads, conflicts, retries, and user expectations all need deliberate handling.
Practical example: withdrawal versus like count
Withdrawal balance
Assumption: a withdrawal is allowed only when the latest committed balance is sufficient.
A deposit or earlier withdrawal updates the balance.
Another withdrawal request reads the balance.
If that read is stale, the service may approve money that is no longer available.
The balance check therefore needs a strong consistency guarantee or a transaction that provides the required equivalent protection. Correctness matters more than serving a stale response quickly.
Social-media like count
Assumption: a viewer can tolerate a temporarily stale aggregate count.
A user likes a post.
One replica receives the update before another.
Some viewers briefly see the older count.
The count converges as the update propagates.
Here, eventual consistency is often acceptable because a short delay does not usually break a critical business rule. The like action itself should still be stored safely and made idempotent where retries are possible.
Try this today
For each field in one of your systems, write down:
What is the worst consequence of a stale read?
How long can the value be stale?
Must two users make decisions from the same latest value?
What should the interface show while replicas converge?
Then choose the weakest consistency guarantee that still preserves correctness. This often produces a better design than selecting one model for every read.
A completed example you can copy
Access pattern: Show the remaining inventory for a product.
Decision: Use a strong or transactional check when accepting the order, because overselling breaks a business rule. The browsing page may use a cached or eventually consistent count if the interface labels low-stock states conservatively and checkout revalidates inventory.
Reasoning: The same data can support two access patterns with different guarantees. Product browsing optimizes responsiveness; order acceptance protects correctness.
Common mistakes
Treating eventual consistency as data loss. Temporary staleness and lost writes are different failures.
Assuming strong consistency automatically makes a multi-step business operation atomic. Transactions, concurrency control, and idempotency may still be required.
Choosing one guarantee for the whole application instead of evaluating each read and write path.
Ignoring the user experience when a value can move backward or appear stale.
Claiming eventual consistency is always faster or strong consistency is always unavailable. The actual trade-off depends on the database, topology, and failure mode.
Knowledge check
1. Which example most clearly needs the latest committed value: a withdrawal balance or a visible like count?
The withdrawal balance, because a stale value can approve an invalid financial decision.
2. Does eventual consistency mean replicas never agree?
No. When new updates stop and replication succeeds, replicas converge.
3. Can one product use both models?
Yes. Choose the guarantee per access pattern; checkout and browsing can have different requirements.
Download the notes
day-11-handwritten-notes.pdfContinue learning with Korshub
Use the Mastering the System Design Interview course to practise explaining requirements, trade-offs, failure modes, and data guarantees clearly in interviews.
Navigation
Previous: Day 10 - CAP Theorem
Roadmap: System Design in 30 Days
Next lesson: Day 12 - Consistent Hashing
