Respecting Cause and Effect
Sometimes eventual consistency is too weak (users get confused by seeing effects without causes), but strong consistency is too slow (the latency cost is unacceptable). Causal Consistency offers a practical sweet spot used by systems like MongoDB (with causally consistent sessions) and some versions of COPS (Clusters of Order-Preserving Servers).
It guarantees that operations that are causally related are seen by everyone in the same order. Operations that are not causally related (concurrent, independent operations) can be seen in different orders by different nodes — and that's fine.
This relies on the "happened-before" relationship: operation A happened-before operation B if A could have influenced B (A was a write that B's client read before issuing B).
Example: Social Media Comment
- User A posts a photo ("Write P").
- User B sees the photo ("Read P") and posts a comment ("Write C").
Here, "Write P" caused "Write C" — B's comment only makes sense in the context of A's photo. There is a causal dependency.
- Under Eventual Consistency: User C might see the comment "Write C" before they see the photo "Write P". This is deeply confusing: "What is this comment referring to?"
- Under Causal Consistency: The system tracks the causal dependency (using vector clocks or similar mechanisms) and ensures that anyone who sees "Write C" must first be able to see "Write P". The cause is always visible before the effect.
What Causal Consistency Does NOT Guarantee
Causal consistency only orders causally related operations. If User D posts a completely unrelated status update at the same time as User A's photo, different nodes may see these two events in different orders — and that's acceptable, because neither caused the other.