Causal Consistency

Causal Consistency

Causal consistency orders the operations on the same key and leaves the operations on other keys alone. The name comes from cause and effect.

A customer with ID 1 cares only about key 1. The requests for it are a read, a write of 31 and another read, and the expected responses are 21 and then 31. Under linearizability the last read is blocked on every request before it, including the reads and writes of key 2, which wastes resources.

The fix is to extract the requests for the same key and order them sequentially: read 1, write 1 to 31, read 1. Key 2 gets its own order: write 7, two reads, write 17.

A global lock on the key does not give this order. Three operations fighting for the lock on key 2 let the write of 17 win, and the two reads return 17 instead of 7. Causal consistency needs ordering, not locks.

It is more consistent than eventual consistency and more efficient than linearizable consistency.

Data Consistency Levels Tradeoffs

Each of the four consistency levels trades consistency against efficiency.

1. Linearizable has the highest consistency and the lowest efficiency, because of head of line blocking: a request waits on a lot of requests that are irrelevant to it. It also keeps aggregations consistent.
2. Eventual has the lowest consistency and the highest efficiency. Data is read quickly from the database, with no order between reads and writes.
3. Causal has high consistency, because the reads and writes for a particular key are ordered. Its efficiency is rather high in most cases, because the operations are point updates and point reads.
4. Quorum has configurable consistency and configurable efficiency.

The drawback of a quorum is cost: it needs multiple nodes. An even number of replicas risks the split-brain problem, and one replica is a single point of failure, so the count is three or five.

Different parts of one system can run at different levels. A server or a cache can run at eventual consistency while the database runs at the highest level.