Consistency Models: Linearizable to Eventual

What a read is allowed to return

A consistency model is a contract about which values reads may return. Linearizability (strong consistency) makes a replicated object behave as if there were one copy: every operation appears to take effect atomically at some instant between its start and its end, and once any read sees a new value, all later reads see it too. Sequential consistency keeps a single global order consistent with each client's own program order, but that order need not match real time. Causal consistency only promises that causally related operations are seen in the same order by everyone; concurrent ones may be seen in different orders. Eventual consistency only promises that replicas converge if writes stop. Stronger models are easier to program against but need more coordination, and therefore more latency. Consensus is the standard way to build linearizable storage, which is why etcd and ZooKeeper sit underneath so many systems.

The cricket score

Linearizable: everyone checking the score sees the same latest run, the moment it is scored. Eventual: one friend's app shows 150 while yours shows 146 for a few seconds, but both catch up. For chatting about the match, eventual is fine; for deciding the winner of a bet, you want linearizable.

Read-your-writes is not linearizability

Read-your-writes only promises that a client sees its own updates. Other clients may still read stale data. Interviewers like to check whether you can tell these session guarantees apart from system-wide models.

त्वरित जाँच: Client A's write completes. Afterwards client B starts a read. Under linearizability, what must B see?

• The value written by A, or a later one
• Any value that was ever written
• A's value only if A and B talk to the same replica
• A's value only after a fixed replication delay