The verdict
Use strong consistency when correctness depends on every reader immediately seeing the latest write — money, inventory, uniqueness constraints. Use eventual consistency when availability and scale matter more than instant agreement and the application can tolerate brief staleness — feeds, view counts, caches. This follows from CAP/PACELC: to stay available under a network partition (and low-latency even without one), you must relax strong consistency. Decide per operation, not per system.
How to decide
- 1Ask what actually breaks if a reader sees data a few seconds stale.
- 2State your availability and latency SLOs — strong consistency costs both.
- 3Can the operation be made idempotent or reconciled later? That favors eventual.
- 4Does the user need to see their own writes immediately (read-your-writes)?
- 5Choose per data type. Most real systems mix strong (payments) and eventual (feeds).
The options
Strong consistency
Every read reflects the most recent committed write.
Best for
- Money, balances, and inventory
- Uniqueness (usernames, idempotency keys)
- Anything where stale reads cause incorrect behavior
Strengths
- Simple mental model — reads always current
- Correctness for invariants and constraints
Weaknesses
- Lower availability under partitions (must reject or block)
- Higher latency — coordination/quorums across nodes
- Harder to scale writes globally
Eventual consistency
Replicas converge over time; reads may briefly be stale.
Best for
- Feeds, timelines, like/view counts
- Caches and denormalized read models
- Globally distributed, high-availability systems
Strengths
- High availability and low latency, even under partitions
- Scales reads and writes horizontally
Weaknesses
- Application must tolerate/resolve stale or conflicting reads
- Needs care for read-your-writes and conflict resolution
- Harder to reason about; subtle bugs
Trade-offs at a glance
| Dimension | Strong consistency | Eventual consistency |
|---|---|---|
| Guarantee | Latest write always | Converges over time |
| Availability under partition | Reduced | High |
| Latency | Higher (coordination) | Lower |
| Write scalability | Harder | Easier |
| App complexity | Lower | Higher (conflicts, staleness) |
| Typical use | Payments, inventory | Feeds, counts, caches |
In the interview
When you pick a datastore or a replication strategy, or directly as 'what consistency does this give you?' The interviewer wants CAP/PACELC reasoning applied to the actual feature, not recited.
What a Staff answer includes
A Staff answer frames the choice through CAP/PACELC, decides per operation, and names the techniques that soften eventual consistency — read-your-writes, quorums, version vectors/CRDTs, sagas. It can explain, in plain terms, what 'eventually consistent' means for the user's experience.
Follow-ups you should expect
- →What does 'eventually consistent' mean for this specific screen the user sees?
- →How do you give a user read-your-own-writes on an eventually-consistent store?
- →How do you resolve conflicting concurrent writes?
- →Which parts of this system need strong consistency, and which don't?
Common mistakes
- ✕Defaulting to strong consistency everywhere 'to be safe' — killing availability and scale.
- ✕Assuming eventual is fine without checking read-your-writes needs.
- ✕Conflating consistency models (linearizable vs sequential vs causal).
- ✕Ignoring replication lag on read replicas (it is eventual consistency).
Further reading
Related decisions
SQL vs NoSQL
Default to relational (Postgres). Reach for NoSQL only when a specific access pattern or scale requirement makes relational a poor fit.
Replication vs Sharding
Scale reads first with read replicas; split by feature (functional partitioning) when parts of the schema have different load; shard (horizontal partitioning) only when a single primary can't handle the writes or dataset. Exhaust caching and replicas before sharding.