Consistency Models: Strong, Eventual, Causal
You'll learn to
- -Compare strong, eventual, and causal consistency
CAP tells you that you can't always have perfect consistency and perfect availability simultaneously. Consistency models describe, more precisely, what "consistency" actually means in practice, and you already have hands-on experience with two of them from earlier modules, even if they weren't named yet.
Strong Consistency
Every read reflects the most recent write, no matter which replica answers. This is the simplest model to reason about, and the most expensive to guarantee across multiple machines or regions: every read may need to coordinate with the source of truth.
Eventual Consistency
Replicas are allowed to disagree temporarily, but will converge to the same value if no new writes arrive. You've already been relying on this: a CDN edge cache serving a slightly-stale page, or a database replica lagging by a few milliseconds, are both examples of eventual consistency in action.
Causal Consistency
A middle ground: operations that are causally related (a reply to a comment) are guaranteed to be seen in the correct order by everyone, while unrelated operations can be reordered freely. It gives you the one guarantee users actually notice ("the reply never appears before the comment it's replying to") without paying for full global ordering of everything.
Strong consistency always reads from the leader; eventual consistency can read from any replica, trading a small chance of staleness for lower latency and higher availability.
In interviews, the strongest answers name which model a specific piece of the design needs, not the whole system. A payment balance needs strong consistency; a "likes" counter is fine as eventually consistent.
A user posts a comment, then immediately refreshes and doesn't see it. What consistency-model question does this raise?
"That's just a bug: the comment should always show up immediately."
"Whichever replica served that read may simply not have caught up yet, which is expected behavior under eventual consistency, not a bug. What actually matters is whether that specific read path needs read-your-own-writes consistency (route a user's own reads to the leader, or to whichever replica just accepted their write), a middle ground that's stronger than plain eventual consistency but doesn't require full strong consistency for every reader."