When we build systems that avoid coordinating, we end up building components that make assumptions about what other components are doing. This, too, is fundamental. If two components can't check in with each other after every single step, they need to make assumptions about the ongoing behavior of the other component.
One way to classify these assumptions is into optimistic and pessimistic assumptions. I find it very useful, when thinking through the design of a distributed system, to be explicit about each assumption each component is making, whether that assumption is optimistic or pessimistic, and what exactly happens if the assumption is wrong. The choice between pessimistic and optimistic assumptions can make a huge difference to the scalability and performance of systems.
email@example.com (Marc Brooker) | Optimism vs Pessimism in Distributed SystemsJosh Beckman
- [Leases](https://dl.acm.org/doi/10.1145/74851.74870) are a nearly u...from firstname.lastname@example.org (Marc Brooker)
- Direct manipulation of data - something like sketch pad - where you...from youtube.com
- the smaller the interface, is the more useful it is [[See also [dee...from The Go Programming Language
- errors are values The Go Programming Language | Gopherfest 2015 |...from The Go Programming Language
- don't communicate by sharing memory share memory by communicat...from The Go Programming Language
- General notes: > Instead of writing code, directly manipulate da...from youtube.com
- **Oozification** is the process of recursively replacing systems ba...from Ribbonfarm Studio
- Le Chatelier’s Principle. This Law states that any natural process,...from John Gall and D.H. Gall