Why is causal consistency often cited as the strongest consistency model that a distributed data store can provide while still remaining available under network partitions, and what does a team give up if they choose a stronger model instead?

## The result the claim rests on The claim rests on a specific theoretical result, developed initially by **Mahajan, Alvisi, and Dahlin** and later given a rigorous formal treatment by **Attiya, Bailis, and Fekete** (often abbreviated as the **CAC** — causal consistency + availability — line of work): among the standard hierarchy of consistency models, causal consistency is the strongest one that can be implemented by a system that is - **always available** — every non-faulty replica answers every request; - **low-latency** — answers don't wait on remote coordination; - **tolerant of network partitions**. The mechanical reason is almost definitional once you look at what causal consistency actually requires a replica to check: to safely apply and expose operation B, the replica only needs to confirm that B's own causal dependencies — the writes the issuing client actually read or wrote before performing B — are already present. Crucially, those dependencies are, by the definition of causality, things that already reached the requesting client through some prior interaction, and therefore have already had a chance to propagate through normal replication to any replica that will now serve B. No replica ever needs to synchronously ask a possibly-unreachable peer 'has anything else happened that I don't know about yet?' — it only needs to know about the specific, already-observed things B depends on. ## Why anything stronger cannot stay available Contrast that with any model strictly stronger than causal — sequential consistency or linearizability, for instance — which require establishing an agreed order among operations that may be entirely concurrent and mutually unknown to each other, including operations neither replica has causally observed yet. Determining that order requires the replicas involved to communicate about the fact of each other's existence in real time, precisely the kind of cross-replica coordination a network partition can block. In CAP terms, causal consistency sits at the boundary: - it's the strongest model on the **AP** side of the trade-off; - while anything stronger forces a system into **CP** behavior — during a partition, a CP system must refuse to serve some subset of requests (or serve them only from whichever side has quorum) rather than risk two sides of the partition disagreeing about a total order they can't currently coordinate on. ## What a team gives up by staying at causal The cost a team accepts by staying at causal consistency is that it provides no help at all for invariants that require a true, system-wide total order across operations that are not causally related. The textbook examples: - selling the last unit of inventory; - enforcing a globally unique username; - preventing a double-spend on an account balance. Two clients performing these operations concurrently, from different regions, are — by definition — concurrent, not causally related, so a causally consistent system is free to let both locally 'succeed' independently, leaving the application to reconcile an outcome that may be fundamentally irreconcilable (you can't un-sell a physical item already promised to two different people). For invariants like these, a team genuinely needs stronger coordination — consensus, a single-writer partition, or a synchronous quorum check — and has to accept the corresponding latency and availability cost, at least on that specific code path, even if the rest of the system happily runs on causal consistency. ## The failure modes A common production failure mode is a team mismatching the guarantee to the invariant in either direction: - assuming causal consistency silently prevents a race condition it was never designed to prevent, leading to double-allocation bugs under concurrent load; - or, more conservatively, defaulting an entire system to strong/linearizable consistency out of caution and paying a global coordination tax on every operation, including the vast majority that never actually needed a total order. There's also a subtler practical gap between the theorem and a given implementation: the CAC result establishes a ceiling on what's theoretically achievable, but a specific causally consistent system can still erode its own practical availability if it isn't engineered carefully — for example, if a replica blocks indefinitely waiting for a slow dependency to arrive (the **causal-stalling** failure mode) rather than bounding that wait, the deployed system behaves worse than the theorem's ideal. ## Where it shows up A concrete real-world illustration of teams actively exploiting this result is Bailis et al.'s **Bolt-on Causal Consistency** work, which retrofits causal consistency as a shim layer on top of existing, already-deployed eventually-consistent stores like **Cassandra** — explicitly motivated by wanting causal ordering's stronger guarantees without sacrificing the underlying store's availability, precisely because the theory says that trade isn't necessary.