Consistency Models: Strong, Eventual and In Between

The spectrum

1. Linearizability (strong consistency)

Linearizability is a rule that says the system must behave as if there were only one copy of the data. Every operation seems to happen instantly, at one moment between its start and its finish. Think of one shared notebook that everyone reads and writes in turn.

• Once a write completes, every later read, by anyone, anywhere, sees it (or something newer).
• Once any reader sees a new value, no reader can see the old one again.

Needed for:

• uniqueness (usernames, one booking per seat),
• locks and leader election (picking one server as the leader, and never two),
• account balances and money movement,
• "compare-and-set" operations (change a value only if it still has the value you expect, for example "set to 11 only if it is still 10").

How it is done: read from the single leader, or use a consensus protocol. A consensus protocol (such as Raft or Paxos) is a set of steps that lets several servers agree on one value, even if some servers fail. Some systems also use carefully designed quorums. A quorum is a majority of the copies that must answer before an operation counts. Cost: extra messages between servers, and part of the system can become unavailable during a network partition (a break in the network, see CAP).

2. Sequential consistency

Sequential consistency is a rule that says all nodes (servers) see the operations in the same order, and each client's own operations stay in the order the client made them. But the shared order does not have to match real time. It is a little weaker than linearizable. You will mostly meet it in theory and in CPU memory models (the rules for how processor cores see each other's writes).

3. Causal consistency

Causal consistency is a rule that says: if one event caused or depends on another, everyone sees them in that order. Events that are not related can show up in different orders for different people. Example: a reply must never appear before the question it answers.

Causal consistency is a good middle choice. It stops the most confusing problems (answers before questions, comments on posts you cannot see). It still allows high availability and speed.

4. Session guarantees (per-client rules)

Session guarantees are small promises made to one client (one user session). They are easy for users to notice. They were described in early research on distributed systems, and many databases and apps use them. Do not mix them up: causal consistency orders events for everyone, while a session guarantee only protects one user's own view.

• Read-your-writes: after you write something, you always see it. (Your comment doesn't vanish after refresh.)
• Monotonic reads: once you've seen a value, you never see an older one later. (Your like count never goes 102 → 99 → 102.)
• Monotonic writes: your writes are applied in the order you made them. (Changing your name to "A" and then "B" never ends up as "A".)
• Writes-follow-reads: if you read something and then write based on it, your write is ordered after what you read. (Your reply is never placed before the post you replied to.)

Lesson 24 showed how to build the first two. Read a user's own data from the leader, and keep each user on the same replica.

5. Eventual consistency

Eventual consistency is a rule with one promise: if no new writes happen, all copies will end up with the same value. Ending up the same is called "converging". The rule does not say when this happens. It also does not say what you see before then.

In practice, "eventually" is usually milliseconds to seconds. During failures or heavy load it can take much longer.

Fine for:

• like and view counts,
• follower counts,
• "last active" status,
• search indexes,
• recommendation lists,
• CDN-cached pages,
• DNS.

How copies converge: handling conflicts

In multi-leader and leaderless systems (lesson 24), two copies can accept different writes to the same data at the same time. This is a conflict. Something must decide the final value. There are four common ways.

Last-write-wins (LWW). This is a rule that gives each write a timestamp and keeps only the write with the latest one.

• ✅ Simple, and used widely (Cassandra uses timestamps this way).
• ❌ Silently discards the other write.
• ❌ Relies on clocks, and clocks on different machines drift apart (see below).

Version vectors (vector clocks). A version vector is a small list of counters, one per node. Each write carries the list, so it records which versions it has already seen. With this list the system can tell if one write came after another, or if the two writes were truly concurrent (made at the same time without seeing each other). Only concurrent writes are real conflicts. They can then be merged, or shown to the app. Amazon's Dynamo used vector clocks to find conflicting cart versions.

CRDTs (Conflict-free Replicated Data Types). A CRDT is a data type built so that any two copies can always be merged automatically. The result is the same whatever order the merges happen in. Examples:

• G-Counter / PN-Counter: a G-Counter only counts up. Each replica counts its own increments, and the total is the sum. Two replicas that both add likes never lose any. A PN-Counter uses two G-Counters (one for adds, one for removes) so it can also count down.
• OR-Set (observed-remove set): a set where you can add and remove items (like cart items). A remove only deletes the adds that the remover had seen, so a new add made at the same time is kept.
• Sequence CRDTs: for collaborative text editing.

CRDTs power features like collaborative editing and offline-first apps, and are available in some databases (for example, Riak, and Redis Enterprise's active-active mode).

Application-level merge. Keep both versions and let the app, or the user, decide. For example: "This document was edited on two devices. Which version do you want to keep?"

Time and ordering: why clocks are tricky

Distributed systems often need to know what happened first. But:

• Physical clocks drift. A physical clock is the normal wall clock on a machine. Servers keep their clocks close using NTP (Network Time Protocol, which copies the time from a trusted server). They can still be off by milliseconds, and sometimes much more. A write with a "later" timestamp might really have happened earlier.
• Leap seconds and clock jumps have caused real outages. A leap second is one extra second that is added to the world clock now and then.

Solutions:

• Lamport clocks: a Lamport clock is a simple counter. It goes up with every event, and it also jumps ahead when a message with a bigger number arrives. This gives an order that respects cause and effect, and it does not use wall-clock time. (Leslie Lamport's classic 1978 paper.)
• Hybrid Logical Clocks (HLC): an HLC joins physical time with a logical counter, so timestamps stay close to real time and still keep cause before effect. Databases like CockroachDB use them.
• TrueTime (Google Spanner): TrueTime is Google's clock service. Special time servers with GPS receivers and atomic clocks give each machine the current time plus an uncertainty range (a few milliseconds). Spanner deliberately waits out that uncertainty before it finishes a commit. This way, timestamps always match real-time order. That is how it offers strong consistency across the globe.

The cost of strong consistency

Strong consistency across continents means waiting for messages to cross oceans. So global systems often keep most data eventually consistent. They make only the critical operations strongly consistent. (These times are typical rough numbers, not fixed rules.)

Matching models to features