Consistency Models: Strong, Eventual, Causal

The CAP theorem says you cannot always have perfect consistency and perfect availability at once. But consistency is not a single switch. Systems offer a ladder of guarantees between everyone always sees the same thing and replicas may disagree for a while, and choosing the right rung for each piece of data is a core design skill. You have already met two of the rungs in earlier modules without naming them.

A team needs to share the notes of a meeting. In the first approach there is one whiteboard in the room and everyone reads from it, so everyone always sees the same thing, but you have to go to the room. In the second, the notes are emailed to each person: for a while different people hold different versions, but once every email has arrived they all agree. In the third, a group chat: unrelated messages may arrive in a slightly different order for different people, but a reply never shows up before the message it replies to.

• -The single whiteboard is strong consistency.
• -The emailed copies that agree once everything has arrived are eventual consistency.
• -The group chat that keeps replies after their messages is causal consistency.

Every read reflects the most recent write, no matter which replica answers. It is the simplest model to reason about, and the most expensive to guarantee across machines or regions, because a read or write may have to coordinate with the source of truth. Between two continents, one coordination round trip alone costs roughly 100 milliseconds or more, which is why it is spent only where it matters.

Replicas may disagree temporarily, but if no new writes arrive they will converge on the same value. You have already relied on this: a CDN edge serving a slightly stale page, or a database replica lagging by a few milliseconds, are both eventual consistency at work. It is cheap and fast and stays available during partitions, but a reader can briefly see old data.

A middle ground. Operations that are causally related, such as a reply to a comment, are guaranteed to be seen in the correct order by everyone, while unrelated operations can appear in any order. To see why that matters, take a post and a reply. Alice posts Anyone want pizza? and Bob replies Yes! Under plain eventual consistency, one replica may receive Bob's reply before Alice's post, and Carol, reading from it, sees Yes! with no question above it. Causal consistency makes that replica hold the reply back until the post it depends on has arrived. It gives users the one guarantee they really notice, without paying for a single global order of everything.

The diagram contrasts the two ends: strong consistency reads from the leader, eventual consistency can read from any replica.

Often what users need is not a global promise but a guarantee about their own experience. Two are worth knowing by name:

• -Read-your-writes: after you change something, you always see your own change, even if other people briefly still see the old version. This fixes the profile photo that appears not to save.
• -Monotonic reads: once you have seen a newer value, you never see an older one. Without it, refreshing a page could show 12 comments, and refreshing again, which happens to hit a lagging replica, could show 10.

• -A payment balance, stock for the last item, a unique username: strong consistency, and accept the latency.
• -Like counts, view counts, recommendations: eventual consistency is fine, and much cheaper.
• -Comments, chat, collaborative lists: causal consistency, or at least read-your-writes for the author.

In an interview, the strongest answers name the model needed by each piece of the design, rather than one model for the whole system, and say what that choice costs.