Consistency Models

SYSTEM DESIGN SERIES  ·  TOPIC 12 OF 23+  ·  part of the 11 → 12 → 13 chain
1. What Does a Reader Actually See?
Same write, same replica - but a very different answer depending on the model (looping)
Strong: the write reaches every copy before any read is allowed to return
Strong: a read right after the write still gets the new value - always
Strong: behaves as if there's only ever one copy of the data
Eventual: the write lands on the leader; replicas catch up on their own time
Eventual: a read too soon can catch a replica that hasn't caught up yet
Eventual: the same read, later, is correct - "eventual" is a promise, not a deadline
2. Strong Consistency (Linearizability)
The system pretends there's only ever one copy
  • Every read reflects the most recently completed write, full stop
  • Simplest mental model - behaves like a single machine, even though it isn't
  • Usually needs synchronous replication (topic 11) or consensus (topic 19)
  • The safety is real, but so is the latency and availability cost
📞 Analogy: calling someone right now and asking. You get the true, current answer - but you have to wait for them to pick up.
3. Strong vs Eventual, Side by Side
Strong
  • Every read = the latest write
  • Costs latency, sometimes availability
  • One predictable mental model
VS
Eventual
  • Reads may be stale, briefly
  • Fast, highly available
  • Converges - but timing isn't promised
📨 Analogy: Strong is calling someone directly. Eventual is a message forwarded through five people - it'll arrive, correctly even, just not on any schedule you can promise.
4. The Middle Ground
Useful guarantees that are weaker than strong, but stronger than "eventually, maybe"
  • Read-your-own-writes - you always see your own write, even if others don't yet (topic 11's fix)
  • Monotonic reads - you'll never see an older value than one you already saw
  • Causal consistency - a question and its answer are seen in the right order by everyone, even if unrelated writes aren't
🎯 Most real systems don't pick pure strong or pure eventual - they pick exactly one of these guarantees, deliberately, per feature.
5. CAP Theorem - During a Partition, Pick One
Not a rule for all the time - a rule for when the network splits
  • Consistency or Availability - pick one, only while the network is actually Partitioned
  • No partition? You can have both - CAP says nothing about the calm times
  • PACELC extends it: even without a partition, there's still Latency vs Consistency to trade
6. Who Chooses What
Real systems, real trade-offs, already made for you
RDBMS + Sync Replicas
leans CP
DNS
leans AP
Cassandra / DynamoDB
tunable, quorum-based
ZooKeeper / etcd
CP, consensus-based
Same theorem four completely different, deliberate answers
Tunable systems are the honest answer. W + R > N (topic 11) lets you dial toward strong or toward eventual, per query, instead of picking once for the whole database.
7. Choosing Your Consistency Model
Choose strong when:
✔ Account balances, inventory counts
✔ Stale = wrong, not just outdated
✔ You can afford the latency cost
Consistency Is a Spectrum, Not a Switch - Pick Per Use Case
Choose eventual when:
✔ Likes, views, follower counts
✔ Caching layers, analytics, DNS
✔ Availability matters more than freshness
💡 Even inside one database, concurrent transactions raise this exact question. That's Isolation Levels - topic 13, next.