> Distributed algorithms require more coordination. Sometimes! There's a whole body of research about when distributed algorithms require coordination. One exa

> 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 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 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 cache misses. Sure, but it's not clear why this is possible in a local context and not a distributed one (and, in fact, in may be easier in the distributed context). One example of how it's easier in the distributed context is snapshotting in MemoryDB (https://brooker.co.za/blog/2024/04/25/memorydb.html https://brooker.co.za/blog/2024/04/25/memorydb.html). > But then you lose the assumption "recently inserted rows are close together in the index", which I've read can lead to significant slowdowns. Or significant speed ups because you avoid false sharing! > Maybe there's also a cultural element to this conflict. What if the engineers interested in "efficiency" are different from the engineers interested in "horizontal scaling"? This is, of course, a false dichotomy. Distributed systems don't only (or even primarily, in most cases) exist for scaling, but availability, resilience, durability, business continuity, and other concerns. To make this purely about scalability is naive. > I'm not sure where this fits in but scaling a volume of tasks conflicts less than scaling individual tasks Indeed. Coordination avoidance is the fundamental mechanism of scaling. This is visible in CALM, in Amdahl's law, and in many of the other frameworks for thinking through this space. > If you have 1,000 machines and need to crunch one big graph, you probably want the most scalable algorithm. If you instead have 50,000 small graphs, you probably want the most efficient algorithm, which you then run on all 1,000 machines False dichotomy again. Algorithms can be both efficient and scalable, and the true shape of the trade-off between them is both super interesting and an ongoing research area. I normally enjoy Hillel's writing and thoughtfulness, but this post seems like a big miss.