September 4th, 2024

Pick Your Distributed Poison

The article examines the challenges of distributed systems, emphasizing eventual consistency, tolerable inconsistencies, bootstrapping strategies, and the trade-offs between safety, liveness, and adaptability in system design.

Read original articleLink Icon
Pick Your Distributed Poison

The article discusses the complexities and challenges of distributed systems, particularly focusing on the concept of eventual consistency, which can lead to eventual inconsistency. The author emphasizes that rather than seeking to eliminate inconsistencies, one should accept and choose the type of inconsistencies they can tolerate. The piece explores various strategies for managing distributed systems, such as bootstrapping, which involves regularly destroying and recreating systems to avoid cycles, albeit at the cost of stability and resource management. The author expresses a preference for reproducible and bootstrappable systems, which, while minimizing the need for working memory, come with their own set of challenges, including the inability to detect leaks and manage long-lived properties. The discussion highlights the paradox of striving for safety and liveness in system design while often building systems that rely less on these properties. The author concludes with a personal reflection on their approach to system design, likening it to savoring a chosen "poison."

- Eventual consistency in distributed systems can lead to eventual inconsistency.

- Accepting and managing tolerable inconsistencies is crucial in system design.

- Bootstrapping can help avoid cycles but may introduce instability and resource leaks.

- Reproducible and bootstrappable systems are preferred for their simplicity but have limitations.

- The design of distributed systems often involves a trade-off between safety, liveness, and adaptability.

Link Icon 9 comments
By @rubiquity - 5 months
I don’t agree with much in this writing other than that eventual consistency is a bad choice. Distributed systems are hard but in 2024 there are enough known patterns and techniques to make them less icky. Systems built on total ordering are much more tractable than weaker protocols. Mahesh Balakrishnan’s recent paper[0] on the Shared Log abstraction is a great recipe, for example.

As an aside, I’ve never enjoyed the defeatist culture that permeated operations and distributed systems pop culture, which this post seems to re-enforce.

0 - https://maheshba.bitbucket.io/papers/osr2024.pdf

By @walterbell - 5 months
> Reproducible and bootstrappable systems get a lot of love among neurodivergent people. For good reason: they’re very friendly to those with little working memory but vast amounts of working context.

This is novel yet obvious in retrospect, has it been articulated or surveyed elsewhere?

By @kukkeliskuu - 5 months
Typically there are no guarantees that a distributed system with ”eventual consistency” is is in consistent state as a whole at any point in time. Downstream systems need to be built based on the assumption that the system is perpetually inconsistent.
By @tazu - 5 months
I'm having a hard time understanding what this is about. Is it about Kubernetes tradeoffs?
By @User23 - 5 months
Distributed systems, like interrupts, are something you can’t bullshit and get right. The author is right though that nondeterminism makes systems easier to reason about if you have the right cognitive tools (ie, math).

Here[1] is an example of what rigorous reasoning about distributed systems looks like.

  the non-deterministic algorithm emerges when, abstracting from their mutual differences, we concentrate on what the many algorithms of the class have in common.

 
[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD687...
By @jiveturkey - 5 months
Is this a lay description of CAP theorem? Or is it actually broader than that? I'm having a hard time getting my head around it.
By @mlhpdx - 5 months
That’s really the secret, isn’t it? Deciding, deliberately, what to leave out of a system so that it is possible for the people involved to maintain it. That is perhaps a good definition of software architecture.