Side by side
| Dimension | Strong consistency | Eventual consistency |
|---|---|---|
| Read guarantee | A read reflects writes completed before it began | A read may return an older value |
| Concurrent operations | Appear in one order consistent with real time | May be observed differently across replicas |
| Coordination | Requires an authoritative ordering mechanism | Can defer replica coordination |
| Latency | May wait for leader or quorum communication | Can serve local replicas without waiting for convergence |
| Network partitions | Some requests must block or fail to preserve guarantees | Can keep serving both sides if conflicts are supported |
| Staleness bound | No stale completed writes under linearizable reads | No fixed bound unless separately specified |
| Conflicting writes | Ordered before successful completion | May require merge rules or conflict resolution |
| Typical use | Inventory claims, lease ownership, authoritative state | Feeds, search indexes, aggregate counts |
The differences that matter
The read contract changes application behavior. If a write completes before a linearizable read starts, that read must reflect the write or a later one. An eventual read can miss it. This matters after actions such as changing a password, claiming a seat, or publishing a post. Read-your-writes routing can improve the writer's experience without making every client's reads linearizable.
Strong consistency can move coordination into the request path. A common implementation uses a leader and consensus-backed replication, with reads that establish the leader's authority or use a suitable quorum protocol. Across regions, that coordination can add network latency. Eventual replication can acknowledge locally and propagate later, but the design must explain durability, failover, and conflict handling separately.
During a network partition, a linearizable service cannot successfully answer every request on both disconnected sides. It must reject or delay operations that cannot be served safely. An eventually consistent design can remain available on both sides if it accepts divergent state and has a convergence strategy. Eventual consistency alone does not guarantee availability, and CAP is specifically about behavior during partitions.
The scope of the guarantee matters as much as its strength. Linearizable reads and writes to individual keys do not make a read-modify-write sequence atomic or protect a multi-key invariant. Preventing overselling needs a conditional update or transaction; protecting several balances may need transactional isolation as well. Many systems combine an authoritative transactional store with eventually updated caches, search indexes, and analytics.
Choose Strong consistency when
- A scarce resource must have one winner, using an atomic conditional claim rather than separate read and write operations.
- A completed revocation must affect every subsequent authorization check, so stale permissions are unacceptable.
- Clients must agree on authoritative ownership, configuration, or state transitions before taking conflicting actions.
- The business cannot repair a stale decision afterward, and the required operations may fail or wait when safe coordination is unavailable.
Choose Eventual consistency when
- A stale feed, search result, or displayed count is acceptable, and authoritative state is checked before an irreversible action.
- Users need low-latency regional reads, and the product explicitly tolerates delayed cross-region visibility.
- Offline or disconnected writers must keep working, and the data model has defined merge semantics.
- Derived views can be rebuilt or reconciled from durable source records, with propagation lag monitored separately.
A worked example
One seat, two regions, two different guarantees
Suppose a booking service has one seat left and accepts requests in two regions. Its search index updates asynchronously, with a hypothetical two-second lag during normal operation. Both users may see the seat as available, which is acceptable for discovery. The hold endpoint must send both claims to an authoritative store and atomically change the seat from available to held, recording the hold ID and expiration. One claim succeeds; the other returns unavailable. During a partition, a region that cannot reach the authority must reject or delay new holds rather than allocate its own copy. Search remains eventually consistent, while the claim operation preserves exclusivity. An idempotency key lets a timed-out client retry without creating another hold.
In the interview
- Start with an invariant and a scope: 'A seat can have only one active hold' is more useful than 'the database must be strongly consistent.' Identify the exact operation that must enforce it.
- Describe the client-visible contract. Can another device see old data after a successful write? Does the writer need read-your-writes? Is there a freshness target, and what happens when replication exceeds it?
- Walk through a partition and leader failover. Say which requests continue, which fail, how old leaders are fenced, and what an ambiguous write timeout means for retries.
- Separate consistency from durability and transaction isolation. Expect follow-ups on atomic conditional writes, multi-key transactions, replica reads, cache invalidation, and idempotent retries.
Common mistakes
- Treating strong consistency as synonymous with ACID or serializability. Linearizability concerns real-time operation ordering; serializability concerns transaction execution order. Some applications need both.
- Claiming eventual consistency means data becomes fresh within a fixed number of seconds. Convergence provides no such deadline without an additional bounded-staleness contract.
- Saying a majority quorum automatically guarantees linearizability. Quorum overlap alone is insufficient without correct version ordering, read and write protocols, and membership handling.
- Assuming strong consistency prevents lost updates or overselling by itself. A separate read followed by an unconditional write can still race; the invariant needs an atomic conditional operation or suitable transaction.
Where it comes up
Interview questions where choosing between Strong consistency and Eventual consistency comes up.
- Design a distributed key-value storeThe read and write contract determines replication protocols, conflict handling, and which requests remain available during partitions.
- Design a ticket booking system like TicketmasterSeat discovery can be stale, but creating a hold requires an authoritative atomic claim that prevents two winners.
- Design a payment systemAuthoritative balance changes need transactional invariants, while receipts and reporting views can propagate asynchronously.
- Design a news feed like FacebookFeed fan-out and caches can lag behind durable posts, so the answer should define visibility and read-your-writes behavior.
- Design Netflix's concurrent screen limitAccount-wide slot allocation must avoid admitting extra streams when regions lose contact or leases change owners.
- Design Facebook post searchSearch indexing can be asynchronous, but stale index entries must not bypass current visibility and permission checks.
Questions people ask
What is the difference between strong and eventual consistency?
Under the linearizability definition used here, strong consistency makes operations appear atomic and respects real-time ordering: a read started after a completed write cannot return an older state. Eventual consistency permits stale reads and temporary divergence, but replicas converge after writes stop and updates propagate. The practical difference is whether an application can act on old state safely.
Is eventual consistency always faster and more available?
No. It permits designs that avoid synchronous cross-replica coordination, which can improve latency and partition availability, but an implementation may still wait for remote replicas or depend on unavailable components. Compare the actual acknowledgment, read-routing, and failure policies rather than inferring performance from the label.
Can one system use both strong and eventual consistency?
Yes, and this is often the right design. A booking system can enforce inventory claims atomically while updating search results and availability displays asynchronously. Make the boundary explicit: stale discovery is acceptable, but checkout must validate against authoritative state.