The theory behind why some distributed computations are safely coordination-free, and how to spot which ones are.
Every distributed systems engineer eventually runs into the same wall. You want your system to be fast, available, and correct all at once, and the tools you reach for to guarantee correctness are usually the same tools that slow everything down. Locks, consensus rounds, two-phase commits: they all buy safety by making machines wait for each other. For a long time this felt like an unavoidable tax. Then, in a 2010 keynote, Joseph Hellerstein proposed an idea that later became a proven result with his collaborator Peter Alvaro: coordination is not always the price of correctness. Sometimes it is simply unnecessary, and there is a precise, checkable reason why.
That result is the CALM theorem, short for Consistency As Logical Monotonicity. It gives distributed systems something they had never really had before: a computability-style test for when coordination is required and when it can be skipped entirely. Understanding it changes how you look at almost every distributed feature you build.
What Coordination Actually Costs Us
Before getting into the theory, it helps to see the bill. Coordination protocols such as Paxos and Raft need a quorum of machines to exchange messages and agree before a write is considered final. Inside a single data center that round trip might cost a fraction of a millisecond. Across regions or continents, the same round trip can climb past a hundred milliseconds, because it is bounded by the physical distance the network signal has to travel back and forth. A coordination-free write, by contrast, can complete the moment it lands locally and let the update propagate afterward.
This gap is why engineering teams keep looking for ways to avoid coordination whenever a problem allows it. The trouble, historically, was that nobody had a rigorous way of saying which problems allow it. Teams simply guessed, tested, and sometimes shipped subtle bugs. The CALM theorem replaces the guesswork with a definition.
The Question CALM Answers
The theorem, first sketched in Hellerstein’s 2010 PODS keynote and later formalized, states it plainly: a problem has a consistent, coordination-free distributed implementation if and only if the problem is monotonic. That single sentence is doing a lot of work, so it is worth unpacking both halves. The “if” direction says monotonic problems can always be solved without coordination. The “only if” direction is the sharper claim: if a problem is not monotonic, no clever engineering trick will let you solve it consistently without some form of coordination. This second half is what makes CALM a genuine theorem rather than just good advice, in the same spirit as the impossibility results distributed systems theory is known for, such as the CAP theorem or the FLP impossibility result.
The original paper, Keeping CALM: When Distributed Consistency is Easy by Hellerstein and Alvaro, frames this as a deliberate shift in what “consistency” even means. Rather than defining consistency as an agreed-upon ordering of events across machines, CALM defines it as a deterministic outcome: no matter how messages arrive, get delayed, or get batched, every correct replica eventually computes the exact same answer. That reframing is what opens the door to a computability-style proof, and it was later given a formal grounding using relational transducer networks by Ameloot, Neven, and Van den Bussche.
Monotonicity, in Plain Terms
Monotonicity is a familiar idea from math, and it translates surprisingly cleanly into distributed computing. A computation is monotonic if adding more input can only add to or preserve the output, never take something away or overturn a conclusion you already reached. If a machine has partial information and computes a partial answer, that answer stays true forever, even after more data shows up later. Nothing that arrives afterward can retract it.
Non-monotonic computations do not have that safety net. New information can invalidate something you already decided, so you cannot safely commit to an answer until you are sure no more information is coming. And in a distributed system, the only way to be sure no more information is coming is to coordinate: to check in with everyone else and confirm nothing is still in flight.
| Monotonic operations (coordination-free) | Non-monotonic operations (need coordination) |
|---|---|
| Set union or adding elements to a growing collection | Set difference or removing elements once added |
| Taking a running maximum or minimum | Computing an average or count that must be exact and final |
| Filtering rows that already satisfy a condition | Negation, such as “no other node has done X” |
| Merging conflict-free replicated counters that only increase | Enforcing a unique constraint or exclusive lock |
| Appending immutable facts to a log | Electing a single leader or deciding a winner |
Notice the pattern. The left column never needs to ask “is this really final?” The right column always does, because a later fact could flip the answer. That single question, whether an answer can ever be undone by information you have not seen yet, is the entire test CALM is built on.
Why Monotonic Problems Can Skip Coordination
Once a computation is monotonic, every node can act on whatever partial information it currently has and simply merge results as more arrives, with no risk of ever being wrong. This is exactly the model behind conflict-free replicated data types, or CRDTs, which are widely used in collaborative editors, shopping carts, and counters at companies like Redis and Riak. A CRDT counter that only increments, or a set that only grows, can be updated independently on every replica and merged later in any order, because the merge operation is monotonic by construction. Later research, including work by Laddad and colleagues, has drawn an explicit line connecting CRDT design directly back to CALM’s monotonicity requirement.
This is also why append-only logs, event-sourcing architectures, and streaming systems that only ever add facts tend to scale so gracefully. They are, structurally, monotonic pipelines. Nobody has to ask permission before writing, because nothing written can ever become wrong.
The Other Direction: When You Cannot Escape It
The sharper, more useful half of CALM is the impossibility direction. If your problem genuinely requires knowing that no more conflicting information is coming, such as electing exactly one leader, enforcing “only one person can book this seat,” or computing a final average, then no distributed algorithm can give you a coordination-free, always-correct answer. You are not missing a clever trick. The theorem proves the trick does not exist. This is the same flavor of result as the CAP theorem, except CALM tells you exactly where the line sits for your specific application logic rather than for storage systems in general, which is a meaningfully more actionable answer for someone designing an actual feature.
In practice this shows up constantly. Inventory systems that must never oversell a limited item cannot avoid coordination on that specific check, even if ninety percent of the surrounding application, browsing, adding to a cart, viewing product pages, is perfectly monotonic and coordination-free. The engineering skill CALM teaches is isolating the small non-monotonic core of a system and paying the coordination cost only there, instead of wrapping the entire application in a slow, globally consistent transaction.
Quorums and the Shape of Coordination
When coordination genuinely is required, its cost is not arbitrary either. Consensus protocols like Paxos and Raft need agreement from a majority quorum of replicas before a decision is considered durable, and that quorum size grows predictably with cluster size.
This is the structural reason coordinated systems feel heavier as they grow. Adding replicas for fault tolerance is good for durability, but it also means more machines have to respond before any non-monotonic decision can be finalized. Coordination-free, monotonic paths sidestep this curve entirely, because they never need a quorum in the first place.
CALM in Practice
CALM is not just an academic curiosity. It shaped the design of the Bloom and Dedalus declarative languages built at Berkeley’s BOOM project, and it underpins static analysis tools like Blazes, which scan a program’s data flow to flag exactly where non-monotonic operations create coordination points, so engineers can see the risk before it becomes an incident. Modern streaming frameworks, CRDT-based databases, and eventually-consistent systems like Riak and Cassandra lean on the same underlying insight even when they never mention CALM by name: keep the monotonic parts free-running, and coordinate only around the genuinely non-monotonic decisions.
A quick checklist: is your problem coordination-free?
- Can a node act correctly on partial information, without waiting to see if more is coming?
- Could a later message ever force you to take back or change a result you already gave a user?
- Does the logic involve negation, uniqueness, exact counts, or picking exactly one winner?
- Would merging two nodes’ independent results, in any order, always land on the same final state?
- Can you isolate the non-monotonic step into a small, separate check rather than wrapping the whole workflow in it?
What We Learned
The CALM theorem gives distributed systems something they lacked for decades: a precise line between problems that can be solved without coordination and problems that genuinely cannot. That line is monotonicity. If new information can only add to an answer and never overturn it, every replica can act independently and merge safely, which is exactly the trick CRDTs and append-only architectures rely on. If new information could invalidate a conclusion you have already reached, coordination is not a design choice you failed to optimize away, it is mathematically required. The real skill this theorem teaches is not avoiding coordination altogether, but finding the smallest possible non-monotonic core in your system and paying the coordination cost only there, while letting everything else run free.
