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.
Interview Signal is part of Pro
See a real weak answer next to a real strong one for this exact topic.
Quiz is part of Pro
Test what you just read with a short quiz, and bank the XP.