Keeping CALM: When Distributed Consistency is Easy · HackerPapers discussions

Keeping CALM: When Distributed Consistency is Easy — mentioned by charleshn

Wed, 10 Sep 2025 11:02:11 GMT

Interesting that neither the article nor the comments mention the CALM theorem [0], which gives a framework to explain when coordination-free consistency is possible, and is arguably the big idea behind SEC. [0] https://arxiv.org/abs/1901.01930

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by mjb

Thu, 13 Feb 2025 00:02:14 GMT

> Distributed algorithms require more coordination. Sometimes! There's a whole body of research about when distributed algorithms require coordination. One example is the CALM theorem (https://arxiv.org/abs/1901.01930), and another is the ways that scalable database systems avoid read coordination (https://brooker.co.za/blog/2025/02/04/versioning.html). > Distribution also means you have fewer natural correctness guarantees, so you need more administrative overhead to avoid race conditions. I don't believe this is true. > If we know the exact sequence of computations, we can aim to minimize…

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by steepben

Wed, 04 Dec 2024 22:11:44 GMT

Yes it's a large chunk, but not everything! Marc had a comment on bluesky regarding this: > Many SQL aggregations are monotonic operations (e.g. MAX, SUM, etc) that can be partially completed on each node and then post-merged. Some (e.g. DISTINCT) can be transformed into monotonic ops with some effort. Some aren't possible to do this way. (Ref on monotonicity: arxiv.org/pdf/1901.01930) The benefit of this is that a lot more work is done _close_ to the data. The trend is that bandwidth is getting larger in data centers, but latency isn't improving at the same rate. Reducing the number of round…

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by ojkelly

Tue, 08 Oct 2024 13:12:31 GMT

> Perhaps others have made this connection before…it does feel like some sort of universal law of physics. This has been on my mind too, and I can’t help but think the fundamental concept underpinning it all is causality. Reading about “consistency as logical monotonicity” — CALM [0], after diving into Spanner, there’s definitely something to databases beyond CAP. I’m yet to find a simple and clear law or theorem that captures what you’re hinting to, but it feels like we must be getting close. This has been bouncing around my head for a few years since I first wrote a toy CRDT DB. It seems to…

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by convolvatron

Fri, 27 Sep 2024 16:54:25 GMT

don't forget about calm. its a shame that that isn't the default we reach for, and only struggle when we really need stronger latency. https://arxiv.org/abs/1901.01930

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — HN submission

Tue, 03 Sep 2024 07:28:16 GMT

Keeping CALM: When distributed consistency is easy (2019)

139 points; 27 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by j-pb

Tue, 03 Sep 2024 06:52:56 GMT

The article should really mention CALM (Consistency as Logical Monotonicity)[1], it's much easier to understand and a more fundamental result than CAP. It is also much more applicable and enables people with little experience to build extremely robust distributed systems. Idempotence, CRDTs, WALs, Raft, they are all special cases of the CALM principle. [1]: https://arxiv.org/pdf/1901.01930

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by j-pb

Tue, 03 Sep 2024 06:48:59 GMT

*Between two distributed systems that don't share the same transactionality domain or are not logically monotone. It's easy to see that moving data from one row to another is doable in a clustered database, and could be interpreted as a message being delivered. The point is that you can get exactly once delivery, if your whole system is either idempotent, or you can treat the distributed system as one single unit that can be rolled back together (i.e. side effect free wrt. some other system outside the domain). Both are cases of some form of logical monotonicity, idempotence is easier to see…

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by j-pb

Fri, 08 Mar 2024 16:42:00 GMT

There is a theorem called CALM[1] (Consistency as Logical Monotonicity) that shows that systems are eventually consistent iff they are monotonic. I find that reasoning about consistency is much easier from that perspective, for example it immediately gives you an intuition on why individual CRDTs work. 1: https://arxiv.org/abs/1901.01930

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by mjb

Wed, 31 Jan 2024 18:35:26 GMT

Completely agree. In-region (e.g. at the scale of a US state), CP seems like a clear winner. For more geo-distributed latency becomes challenging, and in environments like IoT and mobile unreliable connectivity becomes challenging. If you're there, you need a principled way of approaching AP (e.g. CRDTs or CALM https://arxiv.org/pdf/1901.01930.pdf).

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by j-pb

Thu, 02 Nov 2023 07:18:43 GMT

It's absolutely bonkers that TLA+ struggles with this, given that a system is eventually consistent IFF it is logically monotonic (CALM) [1]. This also doesn't make intuitive sense to me. Model checking should be easier for monotonic models, because because the total model check can be viewed as a consistent sum of all partial checks. I've collaborated on a monotonic parser once, which was essentially a monotonic logic programming language. One of the key insights was that you can replace backtracking search of the state space with solving a set covering problem where you attempt to find the…

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by mjb

Wed, 07 Jun 2023 13:31:18 GMT

> How do you build a system around a database where values can no longer be valid at any time? This is a difficult problem, and there aren't nice general solutions. If you read the original Amazon Dynamo paper, for example, there's a good discussion of why eventual consistency is OK for their applications (https://www.allthingsdistributed.com/files/amazon-dynamo-sos...), and more in Werner Vogel's CACM article from two years later (https://dl.acm.org/doi/10.1145/1435417.1435432). There are conceptual frameworks (like CALM https://arxiv.org/pdf/1901.01930.pdf) that provide a way to reason…

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — HN submission

Thu, 13 Apr 2023 13:20:28 GMT

Keeping CALM: When Distributed Consistency Is Easy (2019)

2 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by convolvatron

Thu, 06 Apr 2023 22:50:52 GMT

yeah, that was really brief. I was actually hoping for someone to bring up https://arxiv.org/abs/1901.01930 (keeping CALM) for an interesting alternative

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by newhouseb

Sun, 27 Nov 2022 19:51:54 GMT

You might be thinking of this [1] paper? The core idea being if your problem space lends itself to monotonicity (see the paper for a more precise definition than I can give), then you can build a globally consistent database (around a CRDT) where the end-user doesn't need to concern themselves with inconsistent states while consistency is reached. [1] https://arxiv.org/pdf/1901.01930.pdf

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by mjb

Thu, 11 Feb 2021 15:16:44 GMT

Are you familiar with Joe Hellerstein and Peter Alvaro's work in this space? CALM provides something of a unifying theory of mergeable operations, of which CRDTs are an "object orientated" special case: https://arxiv.org/pdf/1901.01930.pdf In practice, designers choose coordination-heavy protocols like consensus for a number of reasons. One is because writes don't or can't be merged. Operations as basic as simple assignment (x = 1;) can't be merged, so that's very real. Another is because readers can't tolerate weak consistency, because their business logic needs to make decisions at a…

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by zzzcpan

Fri, 08 Nov 2019 23:49:44 GMT

> That function can do whatever it wants, including any number of reads, writes, and arbitrary logic based on the reads. But critically, it can't talk back to the calling client, except for to send the final result. If that function can still do everything the client did and the client still has to wait for a transaction - you are only eliminating interactive communications overhead, not actually improving or simplifying anything fundamentally. There is still consensus, coordination happening during that waiting and all of this is still fundamentally incompatible with computers spread across…

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — mentioned by namibj

Tue, 28 May 2019 15:37:03 GMT

There is something based on Bloom IIRC, but the whole concept should be well-described and discoverable from the Keeping CALM paper: https://arxiv.org/abs/1901.01930

Paper and discussion history. A mention is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — HN submission

Sat, 12 Jan 2019 18:59:55 GMT

Keeping CALM: When Distributed Consistency Is Easy

4 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.

Keeping CALM: When Distributed Consistency is Easy — HN submission

Tue, 08 Jan 2019 20:15:13 GMT

Keeping CALM: When Distributed Consistency Is Easy [pdf]

2 points; 0 discussion replies on HN. Paper and source history. A submission is not an endorsement.