Overview
Under strong consistency, once a write succeeds, every subsequent read returns it — simple to reason about, but it usually needs coordination (consensus or a single leader), which costs latency and can block during partitions. Eventual consistency lets replicas accept writes and reconcile asynchronously, so the system stays fast and available, at the cost of temporarily stale reads.
Strong consistency vs Eventual consistency: key differences
| Strong consistency | Eventual consistency | |
|---|---|---|
| Read guarantee | Always latest | May be stale, converges |
| Latency | Higher (coordination) | Lower |
| Availability under partition | May block (CP) | Stays up (AP) |
| Complexity for app | Simple to reason about | Must handle stale/conflicts |
| Examples | RDBMS, Spanner, etcd | Dynamo-style stores, DNS, caches |
When to use Strong consistency
Money, inventory, uniqueness, anything where a stale read causes real harm — correctness must win over availability.
When to use Eventual consistency
Likes, view counts, feeds, caches, cross-region reads — where being fast and always-available matters more than a few seconds of staleness.
Verdict
Pick consistency per use case, not per database. Use strong consistency where correctness is non-negotiable; use eventual consistency to buy availability and low latency where slightly stale data is acceptable.
Common questions
What is the difference between strong and eventual consistency?
Strong: every read sees the latest write immediately. Eventual: replicas may briefly disagree but converge. Strong costs latency/availability; eventual costs occasional stale reads.
How does this relate to the CAP theorem?
During a network partition you must choose: stay consistent and reject some requests (CP), or stay available and serve possibly-stale data (AP). Eventual consistency is the AP choice.