Strong vs Eventual Consistency
Strong consistency guarantees every read returns the most recent write (at the cost of latency and availability), while eventual consistency allows stale reads temporarily (gaining availability and speed) — and the right choice depends on what happens when your system shows outdated data.
Strong consistency: After a write completes, every subsequent read from any node returns that write. The system behaves as if there's one copy of the data. Achieved via consensus protocols (Raft, Paxos) or synchronous replication. Used by: Spanner, CockroachDB, etcd, ZooKeeper.
Eventual consistency: After a write, replicas may temporarily return stale data, but will converge to the latest value given enough time. No coordination overhead on the write or read path. Used by: DynamoDB (default), Cassandra (CL=ONE), S3, DNS.
The question to ask: What's the business cost of showing stale data? If showing a stale bank balance could cause an overdraft → strong consistency. If showing a social media post 2 seconds late is fine → eventual consistency.
Tradeoffs
Strong Consistency — Strengths
- Correctness guaranteed — no stale reads, no conflicting writes
- Simpler application logic — no conflict resolution, no idempotency concerns
- Required for financial data, inventory management, access control
- Easier to reason about — system behaves like a single machine
Strong Consistency — Weaknesses
- Higher write latency (consensus round trips: 1-10ms per write)
- Lower write throughput (serialization overhead)
- Reduced availability during network partitions (CP tradeoff)
- Higher cost: DynamoDB charges 2x for strongly consistent reads
Eventual Consistency — Strengths
- Lower latency (no cross-node coordination on reads)
- Higher availability (any replica can serve reads, even during partitions)
- Higher write throughput (no synchronous replication wait)
- Better multi-region performance (no cross-continent round trips)
Eventual Consistency — Weaknesses
- Stale reads during consistency window
- Conflict resolution complexity (LWW, vector clocks, CRDTs, application-level merge)
- Harder to debug data anomalies
- Application must handle edge cases: double-processing, out-of-order events
- Some business domains simply cannot tolerate stale data (finance, access control)
Likely Follow-Up Questions
- How does replication lag cause eventual consistency, and how do you measure it?
- What is the read-your-writes guarantee and how would you implement it?
- How do CRDTs achieve convergence without coordination?
- How does Google Spanner achieve strong consistency globally?
- What's the outbox pattern and why is it important for event-driven systems?
- How would you handle a scenario where strong consistency is needed for one field but eventual consistency is fine for others in the same record?
Related Concepts
Source: editorial — Synthesized from Amazon Dynamo paper, Google Spanner paper, Stripe engineering blog, and production patterns at Amazon, Netflix, and Figma