The Coordination Criterion

TL;DR

This paper introduces a universal coordination criterion in distributed systems, identifying when coordination is inherently necessary based on observable outcomes and causal history extensions.

Contribution

It provides a general, specification-level criterion for determining the necessity of coordination, unifying various classical results and tradeoffs in distributed computing.

Findings

Coordination-free implementations exist iff outcomes evolve monotonically with causal history extensions.

The criterion applies broadly, explaining protocols, impossibility results, and consistency tradeoffs.

It offers a unified semantic framework for understanding coordination requirements.

Abstract

When is coordination intrinsically required by a distributed specification, rather than imposed by a particular protocol or implementation strategy? We give a general answer using minimal assumptions. In an asynchronous message-passing model, we represent executions as Lamport histories: collections of events partially ordered under happens-before. We abstract away from implementation mechanics and reason only about the observable outcomes that a specification admits at each history. We show that a specification admits a coordination-free implementation if and only if observable outcomes evolve monotonically as the history is causally extended. This Coordination Criterion is stated entirely at the level of specifications, independent of any particular programming language, object implementation, or protocol structure. It yields a sharp boundary between specifications that can be implemented without coordination and those for which coordination is unavoidable. The criterion provides a uniform explanation for a range of classical results, including distributed protocols and impossibility results, CAP-style consistency tradeoffs, CALM-style coordination tests, and programming-language analyses. Each can be viewed as an instance of the same underlying semantic phenomenon.