Overview
Consistency describes what values reads are allowed to return in a system with replicated data. Strong consistency (linearizability) means every read sees the latest completed write, as if there were a single copy. Weaker models (causal, read-your-writes, eventual) allow some staleness in exchange for lower latency and higher availability.
Note that 'consistency' in ACID means something different: a transaction moves the database from one valid state to another, respecting constraints. In distributed systems discussions, consistency almost always refers to replica consistency models, and choosing the right model per operation is a core system design skill.
Strong consistency is everyone editing one live document: you always see the latest text. Eventual consistency is emailing copies: everyone eventually has the same version, but for a while people read different drafts.
When to use it
- Deciding how reads and writes behave across replicas and regions.
- Money, inventory, and uniqueness: strong consistency.
- Feeds, likes, and view counts: eventual consistency is usually fine.
- Explaining user-visible anomalies such as stale or out-of-order data.
Where it shows up in interviews
Recognize it when: different parts of a product need different guarantees.
- Design an e-commerce system
- Design a banking app
Recognize it when: user posts a comment and does not see it.
- Design a social feed with replicas
- Design a collaborative editor
Where it is used in real software
Moved to strong read-after-write consistency for all operations in 2020, removing a common source of bugs.
Offers eventually consistent reads by default and strongly consistent reads at twice the cost.
Provides external consistency globally using TrueTime (GPS and atomic clocks).
Key terms
- Linearizability
- Operations appear to happen instantly at one point in time, in real-time order.
- Sequential consistency
- All nodes see operations in the same order, not necessarily real-time.
- Causal consistency
- Operations that depend on each other are seen in order by everyone.
- Read-your-writes
- A client always sees its own writes.
- Eventual consistency
- Replicas converge if writes stop.
How it works, step by step
- 1List operations
Place order, view cart, like post, show follower count.
- 2Ask what staleness would break
Overselling stock is bad; a like count off by 3 is fine.
- 3Assign a model per operation
Strong for money and uniqueness, session guarantees for user-facing writes, eventual for the rest.
- 4Implement
Leader reads, quorums, consensus, or version tokens.
- 5Communicate in the UI
Optimistic updates and 'processing' states hide eventual consistency.
Consistency models from strongest to weakest
Stronger models cost latency and availability
| Model | Guarantee | Example system / use |
|---|---|---|
| Linearizable | Reads see the latest write | etcd, Spanner, leader reads |
| Sequential | Same global order for everyone | ZooKeeper writes |
| Causal | Cause before effect | Comments after the post they reply to |
| Read-your-writes | You see your own updates | Profile edits |
| Eventual | Converges eventually | DNS, likes, view counts |
NOWModel: Linearizable | Guarantee: Reads see the latest write | Example system / use: etcd, Spanner, leader reads
Most products mix models. The interview skill is naming which model each operation needs and why.
Implementation
// Eventually consistent (cheaper, may be stale)await ddb.send(new GetCommand({ TableName: "posts", Key: { id } })); // Strongly consistent read from the leader replicaawait ddb.send(new GetCommand({ TableName: "inventory", Key: { sku }, ConsistentRead: true })); // Conditional write: only decrement if stock is available (no overselling)await ddb.send(new UpdateCommand({ TableName: "inventory", Key: { sku }, UpdateExpression: "SET stock = stock - :one", ConditionExpression: "stock >= :one", ExpressionAttributeValues: { ":one": 1 },}));Complexity and performance
Cannot use nearest replica.
~100+ ms.
Lowest latency.
Trade-offs
Even without failures, stronger consistency requires coordination, which adds latency.
During a network partition, a system must refuse some requests to stay consistent, or answer with possibly stale data.
Variants and related techniques
Reads may lag by at most a time or version bound (Azure Cosmos DB).
A client never sees older data after seeing newer data.
Common mistakes
- Confusing ACID consistency with replica consistency.
Fix: Clarify which meaning you use in interviews.
- Strong consistency everywhere.
Fix: It costs latency and availability; use it where correctness requires it.
- Eventual consistency without handling anomalies.
Fix: Design idempotent, commutative updates and UI states for pending data.
Interview questions
Which parts of an e-commerce site need strong consistency?
Inventory decrements, payments, order state transitions, and unique constraints like coupon redemption. Product browsing, reviews, recommendations, and view counts can be eventually consistent.
How do you provide read-your-writes with replicas?
Route a user's reads to the leader for a short time after they write, or include the write's log position in the session and read from a replica only after it has replayed past that position.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Assign consistency models to 10 features of a social app | Medium | Per-operation reasoning. |
| Prevent overselling tickets with conditional writes | Medium | Atomic checks. |