Overview
Strong and eventual consistency describe how distributed systems handle replicated data after a write. Strong consistency guarantees every read reflects the latest write by blocking until replicas agree, while eventual consistency returns immediately and lets replicas converge in the background. The choice trades write latency and availability against read freshness.
Comparison Diagram
Comparison Table
| Aspect | Strong Consistency | Eventual Consistency |
|---|---|---|
| Write acknowledgment | Ack returned only after write is durably applied to all (or a quorum of) replicas | Ack returned as soon as the write hits the local/primary node |
| Replication propagation | Synchronous — write blocks until replicas confirm | Asynchronous — replication happens in the background |
| Read guarantee | Every read reflects the most recent write (linearizable) | Reads may return stale data until replicas converge |
| Conflict handling | Prevented upfront via consensus/locking that serializes writes | Resolved after the fact via LWW, vector clocks, or CRDTs |
| Write latency | Higher — pays network round-trip cost to replicas/quorum | Lower — commits locally before propagating |
| Behavior under partition | Unavailable or degraded if quorum can’t be reached (CP) | Stays available, serving from whichever replica is reachable (AP) |
| Typical mechanism | Consensus protocols like Paxos/Raft, synchronous quorum writes | Gossip protocols, anti-entropy repair, background sync |
| Typical use cases | Banking ledgers, inventory counts, leader election | Social feeds, DNS, shopping carts, CDN caches |
Key Differences
- Strong consistency blocks the write until a quorum confirms; eventual consistency acks after a local commit.
- This is the classic CAP tradeoff: strong favors consistency during a partition, eventual favors availability.
- Strong relies on consensus protocols like Raft; eventual relies on background anti-entropy repair.
- Only strong consistency guarantees read-after-write; eventual consistency allows a stale-read window.
When to Use Each
Strong Consistency
- Financial ledgers: Account balances and transfers must never show a stale or conflicting value, so writes need to be serialized.
- Inventory/stock counts: Overselling a limited item requires every reader to see the exact latest count before confirming a sale.
- Leader election / locks: Distributed coordination needs a single agreed-upon truth, which requires consensus rather than eventual agreement.
Eventual Consistency
- Social feed counters: Like and view counts can lag by seconds without harming user experience, so async propagation is acceptable.
- DNS and CDN caching: Global propagation delay is expected and tolerated in exchange for high availability and low latency worldwide.
- Shopping cart state: Cart contents can briefly diverge across replicas and merge later without breaking the checkout flow.