Consistency Patterns — Weak, Eventual, Strong
Consistency patterns describe the guarantees a distributed system makes about what data readers observe after writes. The three families — weak, eventual, and strong — sit on a spectrum trading latency, availability, and complexity against correctness. Understanding which pattern your system needs is the difference between a chat app that feels snappy and a bank ledger that loses money.
How it works
When data lives on more than one machine, the system has to answer a simple-sounding question: after a write succeeds, what do subsequent reads see? The answer is not 'the latest value' — there is no single 'latest' on a distributed system unless you pay for it. Consistency patterns are the named answers to that question, ordered from cheap-and-loose to expensive-and-strict.
The three families you need to internalize:
- Weak consistency: after a write, there is no guarantee a read sees it. Best-effort. Used for voice/video packets, telemetry, ephemeral state.
- Eventual consistency: after a write, if no new writes happen, reads will eventually see it. Convergence, not freshness. Used for feeds, search indexes, DNS, shopping carts.
- Strong consistency: after a write succeeds, any read sees it (or an error, never a stale value). Linearizability. Used for money, inventory, leader election, anything where stale data breaks invariants.
These are not implementations — they are contracts. Many databases let you choose per-request, e.g., Cassandra's consistency levels (ONE, QUORUM, ALL) or DynamoDB's (eventual vs strong). Choosing per-request is the realistic middle ground.
Weak consistency is the 'best effort' model. The system tries to deliver writes to readers, but does not promise. If a packet is dropped, a metric is late, or a cache is stale — the application tolerates it. This is the right model when the data is time-decaying or loss-tolerant: a 50ms snippet of audio in a phone call is useless 200ms later, so retransmitting it would make things worse, not better. Voice/video over UDP, fire-and-forget telemetry, and ad-hoc log fanout are the canonical examples.
The defining property is that a successful write does not imply anything about future reads. There is no convergence promise, no freshness window, no read-your-writes guarantee. Weak consistency is almost never a database setting — it is the default behavior of the network itself, and only applications that can absorb loss opt into it deliberately.
Eventual consistency is the workhorse of the modern web. The promise: if no new writes happen to a key, all replicas will eventually converge to the same value. Note what is not promised: a freshness bound (could be 10ms or 10s), read-your-writes (your own write may not be visible to your next read), or session consistency (sequential reads may go backwards in time).
Convergence is achieved through one of three reconciliation mechanisms:
- Read repair: when a read hits multiple replicas and they disagree, the coordinator writes the newest value back to the stale replicas. Cheap, lazy, only fixes data that someone actually reads.
- Anti-entropy: background processes (Merkle trees in Cassandra,Hinted Handoff) periodically scan replicas and patch divergences. Smooths out unread cold data.
- Application conflict resolution: Dynamo-style systems (Riak, DynamoDB) let multiple conflicting versions exist (siblings) and the application decides how to merge. Last-write-wins is the default, but it loses data when clocks are skewed.
Eventual consistency is the right call when stale data is annoying but not catastrophic: social feeds (a tweet appears 2 seconds late for a follower), DNS propagation (a record takes minutes to spread), search indexing (a new product is searchable in 30 seconds instead of immediately), shopping cart counts. The reason it is so common is not laziness — it is that the latency and availability wins are enormous. A strong-consistency write across 3 regions is 100ms+; an eventual write is local sub-ms.
Strong consistency (linearizability) is the strictest model: after a write returns success, every read by every client sees that write (or a newer one). It behaves as if there were a single copy of the data, even though the data is replicated. This is the model a bank account balance demands: if you transfer $100 and the write succeeds, any subsequent balance check — from any region, on any replica — must reflect it.
Achieving strong consistency requires coordination. The two main techniques:
- Quorum reads/writes: with N replicas, require R readers and W writers where R + W > N. Reads contact R replicas and pick the newest; writes contact W replicas and wait for ack. With R = W = majority, any read overlaps any write — the reader is guaranteed to see a recent write. Cost: each operation touches multiple nodes and waits for the slowest of them.
- Consensus protocols: Paxos and Raft elect a leader that sequences all writes. Reads go to the leader (or to followers with a lease). Cost: leader is a bottleneck, and a leader election during a partition blocks writes.
Strong consistency is expensive. It costs latency (round-trip to a quorum or leader), it costs availability (cannot complete a write if a quorum is unreachable), and it costs throughput (the leader is serialized). Use it for: financial transactions, inventory decrements, distributed locks, leader election, configuration changes, anything where a stale read creates a correctness violation.
The crucial skill is mixing consistency levels within a single system. Stripe, for example, treats charges as strongly consistent but the merchant dashboard's aggregate stats as eventually consistent. Uber treats driver location as eventually consistent but the actual ride assignment as strongly consistent. This is the realistic pattern: pick the cheapest consistency that does not break your invariants.
Between eventual and strong are practical sub-models. 'Read-your-writes' guarantees that after a client writes, all subsequent reads by the same client see it. 'Session consistency' extends that to a session (sticky to a coordinator or replica). These cost less than full linearizability but fix the most jarring UX bugs — like a user posting a comment and not seeing it because they were load-balanced to a stale replica. Most production systems achieve this with sticky sessions or write-through to a primary on writes.
A user updates their profile picture. Their next page load (1 second later) shows the old picture. Which consistency property was violated, and what is the minimum fix?
Pick one answer.
You are designing a banking ledger. Which consistency model is acceptable for the balance, and what does it cost?
Pick one answer.
In a quorum-based system with N=5 replicas, you set R=3 and W=3. What consistency guarantee does this give, and what is the availability cost?
Pick one answer.
Engineering mental model
Mental model. Think of Consistency Patterns — Weak, Eventual, Strong as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Consistency Patterns — Weak, Eventual, Strong mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Consistency Patterns — Weak, Eventual, Strong, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
message_id = queue.publish({
"type": "consistency-patterns",
"key": resource_id
})
# Consumer must be safe to retry.Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: Consistency Patterns — Weak, Eventual, Strong
Change the variables below and predict what breaks first in Consistency Patterns — Weak, Eventual, Strong. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Consistency Patterns — Weak, Eventual, Strong, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Consistency Patterns — Weak, Eventual, Strong. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Consistency Patterns — Weak, Eventual, Strong?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Consistency Patterns — Weak, Eventual, Strong, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Consistency Patterns — Weak, Eventual, Strong, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
For Consistency Patterns - Weak, Eventual, Strong, separate producer speed from consumer speed. The key design question is what happens when production temporarily exceeds processing capacity: queue it, shed it, slow producers down, or degrade the feature.
Numerical sanity check
A simple queue sanity check: if producers create 8,000 messages/s and consumers process 6,000 messages/s, backlog grows at roughly 2,000 messages/s until the imbalance is corrected.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
A downstream service slows down while Consistency Patterns - Weak, Eventual, Strong keeps accepting traffic. Would you rather apply backpressure, queue more work, shed load, or degrade? Explain the trade-off.
Pick one answer.
What you gain, what you pay
- +Naming the consistency model explicitly forces the team to reason about staleness, availability, and latency as a single decision.
- +Per-request consistency levels (Cassandra, DynamoDB) let you pay the strong-consistency tax only for the operations that need it.
- +Eventual consistency unlocks cross-region writes and multi-writer topologies that strong consistency cannot support at acceptable latency.
- +Strong consistency makes distributed bugs tractable — the system behaves like a single machine, so reasoning is local.
- −Strong consistency costs latency (quorum round-trips) and availability (cannot complete without a quorum).
- −Eventual consistency requires application-level conflict handling (last-write-wins loses data; siblings are complex).
- −Mixed consistency in one system creates subtle bugs when a fast path reads stale data that a slow path assumed was fresh.
- −Documenting the actual consistency model is hard; teams often assume stronger guarantees than the database provides.
How this breaks in production
- Last-write-wins on clocks with skew silently drops the later write — use vector clocks or hybrid clocks (Spanner's TrueTime).
- Read-your-writes violation: user posts a comment, page reloads, comment disappears — load balancer routed the read to a stale replica.
- Quorum configured too loosely (R + W <= N) allows reads to miss writes — silent staleness that passes normal testing.
- Strong consistency used for high-fanout reads (trending feeds) — the leader becomes a bottleneck and the system falls over during traffic spikes.
Don't fall into these traps
- •Assuming 'eventual consistency' means 'eventually correct' — it means eventually converged; if two clients wrote conflicting values, convergence does not pick the right one for you.
- •Defaulting every read to strong consistency 'to be safe' — it multiplies your latency bill and breaks availability.
- •Treating session consistency and linearizability as the same — session only guarantees your own writes; other clients' writes can still be stale.
- •Forgetting that strong consistency requires the *quorum overlap*, not just 'synchronous replication' — sync replication to two of three nodes is not linearizable if reads only touch one.
- •Mixing consistency levels without documenting which APIs require which — a refactor six months later silently downgrades a critical read.
Real systems using this
How real systems implement this
- Amazon DynamoDB — Offers eventual consistency by default and a 'strongly consistent' read flag per request. Strong reads cost more capacity units and may fail if the leader region is unreachable.
- Google Spanner — Default linearizable via Paxos groups and TrueTime clocks. Pays the latency cost of cross-region quorums but enables correct distributed transactions.
- Cassandra — Tunable per-request consistency levels (ONE, QUORUM, LOCAL_QUORUM, ALL). The same table can be read with eventual consistency for cheap fanout and quorum for critical reads.
Practice saying it out loud
- Q1Explain the difference between weak, eventual, and strong consistency. Give one realistic use case for each.
- Q2Design a 'like counter' for a social post. What consistency model do you pick, and how do you keep the count both fast and eventually accurate?
- Q3Your system uses Cassandra with consistency ONE for reads. A user reports they sometimes see stale data seconds after their own write. What is happening and how do you fix it without making every read slow?
- Q4When does quorum overlap (R + W > N) guarantee strong consistency, and when does it not? What else do you need?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
Availability Patterns — Failover, Replication, Redundancy