Causal consistency

Which causality can causal consistency never see?

Drop the total order. Keep only the edges that could have carried information.

Happens-before gives those edges. Operation a happens-before b if (1) both are by the same client and a came first, or (2) b read the value that a wrote, or (3) there is a chain of such steps. Causal consistency requires that all replicas observe causally related operations in the same order. Concurrent operations (neither happened before the other) may be seen in any order, and different replicas may disagree about them.

Example: Anika posts a note "Dinner at 8?" and Sam replies "Yes!". Sam's reply depends on Anika's post. Under causal consistency, nobody sees the reply without the post. But two unrelated notes by two unrelated people may appear in different orders on different replicas.

This is the most important boundary in this article: causal consistency is the strongest model that is achievable with total availability. Above it you must coordinate. At or below it you need not. The unification and its price starts from this line.

The price is metadata

Causal consistency has to track who depended on what, and the granularity choice is a new example of the mismatch rule, with the amplification counted in a new unit:

Version vectors cost one entry per writer (a version vector is a small table "writer → latest counter seen" that lets two replicas compare their histories). When clients are writers, clients come and go, and the vector keeps growing. Metadata that grows with the number of writers meets writers that churn.
Explicit dependency lists (each write names the writes it depends on) cost O(reads) per write.
Coarsening to per-partition or per-epoch tracking creates false dependencies. They amplify latency: you wait for predecessors you never actually had. The mismatch between tracking unit and need has now produced write amplification, read amplification, false conflicts, and visibility delay.
Truncating version vectors (to bound their size) manufactures false concurrency: two causally ordered writes look concurrent and must be merged or arbitrated. This is the approximation rule, paid in a new kind of false positive: not a false conflict but a false independence.

The assumption it cannot verify (the best example here)

Potential causality is only what passed through the system. Two examples:

Anika removes her manager from the audience of her notes, then posts a note. The two operations land on different partitions. The manager's replica has the post but not the removal, and shows the note.
Two people are on a phone call. One says "I uploaded it." The other refreshes and sees nothing. The causal edge went through the air.

Nothing logs it, nothing detects it, nothing can. Causal consistency orders the causality it can see, and is structurally silent about the causality users care about most. (This is the hidden-assumption rule at its clearest.)

Bare causal consistency is not deployable

It orders causally related operations and says nothing about concurrent conflicting ones, so you still need a rule that makes replicas converge. Causal consistency is an ordering guarantee with a hole exactly where the conflicts are. Something else fills the hole. This is why the real model is causal+ (from the COPS system): causal ordering plus convergent conflict handling. When someone says "causal consistency", ask which convergence rule fills the hole.

Case, resolvedConstructed case · Anika at Pebble

Fast reads in Singapore, and a balance a second old

After the Singapore region opened, reading the balance from the Frankfurt leader took 160 ms or more, a local replica made it fast but sometimes a second stale, and Tomás asked for local reads and local writes with the strong guarantee. Where it started: Distributed consistency →

Tomás's question. Local reads and local writes with a strong guarantee is forbidden: r + w ≥ d, so with d = 80 ms the sum is at least 80 ms. Anika lays out the four purchases:

Choice for Singapore	Read	Write	What Pebble pays
Leader reads in Frankfurt	~160 ms	quorum round trip	One vantage point: Singapore depends on Frankfurt
Lease-based local reads	~1 ms	quorum round trip	A clock-drift assumption nobody checks
Quorum reads (ABD)	majority round trip plus write-back	majority round trip	Two round trips on the read path
Local reads, local writes	~1 ms	~1 ms	Linearizability itself

For the balance screen she wants linearizability for the write path (transfers stay in Frankfurt) and a stated staleness bound for the Singapore read (never more than 2 s behind, alarmed on). For the notes feed she chooses causal+, so a reply never appears before its post. She also writes a warning: the "friends who may see my notes" removal followed by a post can still leak across a phone call or a second service, and no replica setting closes that channel. That needs The unification and its price.