# Optimism vs Pessimism in Distributed Systems

DevFeed: [Optimism vs Pessimism in Distributed Systems](<https://devfeed.tech/articles/optimism-vs-pessimism-in-distributed-systems-12546.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2023/10/18/optimism.html>)

Author: Marc Brooker

Published: 2023-10-18T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [distributed-systems](<https://devfeed.tech/topics/distributed-systems.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [Cache](<https://devfeed.tech/topics/cache.md>), [Caching](<https://devfeed.tech/topics/caching.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [performance](<https://devfeed.tech/tags/performance.md>), [scalability](<https://devfeed.tech/tags/scalability.md>), [systems](<https://devfeed.tech/tags/systems.md>)

## AI overview

The article explains how optimistic and pessimistic assumptions shape coordination, scalability, and performance in distributed systems. It uses distributed caches and time-to-live expiration to illustrate the trade-offs between avoiding coordination and enforcing bounded staleness.

## Source excerpt

Optimism vs Pessimism in Distributed Systems What--Me Worry? Avoiding coordination is the one fundamental thing that allows us to build distributed systems that out-scale the performance of a single machine1. 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. I generally think of optimistic assumptions as ones that avoid or delay coordination, and pessimistic assumptions as ones that require or seek coordination. The optimistic assumption assumes it'll get away with its plans. The pessimistic assumption takes the bull by the horns and makes sure it will. To make this concrete, let's consider some examples. Example 1: Caches Distributed caches almost always make assumptions about whether the data they are holding is changed or not. Unlike with CPUs2, distributed caches typically aren't coherent, but we still want them to be eventually consistent. By eventually consistent we mean that if the write stream stops, the caches eventually all converge on containing the same data. In other words, inconsistencies are relatively short-lived. Possibly the most common way of ensuring this property--that inconsistencies are short-lived--is with a time to live (TTL). This simply means that the cache only keeps items around for a certain fixed period of time. T