Distributed Consistency Models
The problem
'Consistent' isn't one single guarantee — different applications need different, precisely specified promises about when a write becomes visible to other readers, and choosing too strong a guarantee costs performance while choosing too weak a one causes real, user-visible bugs.
Why now
The CAP theorem established that consistency is a spectrum you trade against availability, but treated 'consistency' as one thing; this topic breaks it into the actual named models engineers choose between, and ACID's isolation levels already hinted that consistency itself has gradations even on a single machine.
Mental model
Strong consistency promises every reader sees the latest write immediately, as if there were only one copy of the data — expensive to guarantee across a network. Eventual consistency promises only that, absent new writes, all copies will eventually agree — cheap and highly available, but a reader can briefly see stale data. Most real systems pick a middle point (like 'read-your-own-writes') that's stronger than pure eventual consistency but cheaper than global strong consistency.
Requires
- The CAP TheoremDistributed Systems
Consistency models are the specific, named points along the tradeoff CAP already identified as unavoidable during a partition; you need that tradeoff established before comparing specific models makes sense.
- Transactions & ACIDDatabase Engineering
ACID's isolation levels already showed that 'consistency' has gradations even within a single database; distributed consistency models are that same idea, stretched across multiple machines instead of concurrent transactions on one.
Unlocks
Used in
- Choosing a consistency model when configuring a distributed database (e.g. DynamoDB's tunable consistency)
- Explaining why a user might briefly see their own comment disappear and reappear after posting (read-your-own-writes violations)
- Caching layers, which are almost always eventually consistent by design
- Multi-region deployments, where strong consistency across regions carries a real, often unacceptable latency cost
Projects
- Simulate eventual consistency with two local data stores syncing on a delay, and demonstrate a stale read during the sync window
- Design a 'read-your-own-writes' guarantee on top of an eventually consistent store, ensuring a user always sees their own recent changes even if others don't yet
Examples
- A user posting a comment and immediately refreshing to not see it, then seeing it seconds later, is a visible eventual-consistency lag
- DynamoDB lets you choose 'strongly consistent' or 'eventually consistent' reads per request, trading latency and cost directly for the guarantee
Resources
- Consistency models — Jepsenarticle
Mastery checklist
- I can explain the difference between strong and eventual consistency with a concrete example
- I can explain what 'read-your-own-writes' guarantees and why it's a useful middle ground
- I can choose an appropriate consistency model given a feature's actual requirements
- I can identify a consistency-related bug (a user seeing stale or disappearing data) and explain its likely cause