You Know State Is NO Good | Yusuf Aytas

I once worked on data deletion because someone wanted to delete their account. We wiped their data, confirmed the rows were gone, verified the cache invalidation in the logs. But they kept showing up in other people's friends lists. Ghost entries. I checked the database. Checked the cache invalidation logic. Looked correct. Checked the logs again. Yet, the fucking phantoms kept coming back anyway.

It turned out to be a race condition. A read slipped into the tiny window between the cache invalidation and the write completing. The stale relationship got cached again the moment we cleared it. Two weeks chasing a bug that lived in a gap measured in milliseconds.

That is what state does to you. It hides in the gaps between operations and waits for the worst possible moment to show up. After enough of these, you start to see stateless design differently. When nothing needs to be remembered, there is nothing to betray you.

Keeping information sounds simple but rarely is. That is why stateless design has become so influential. It challenges the idea that systems should retain internal information between operations. When they do not, they are easier to write, debug, and reason about.

Statefull vs Stateless

Stateless vs. Stateful

A stateful system remembers information between operations. It keeps track of what has happened before, using that stored data to determine how it should behave next. This memory can live in variables, sessions, or persistent storage.

A stateless system works differently. It does not remember anything between executions. Each request or operation is handled in complete isolation. The output depends only on the input, and nothing else.

A simple example in JavaScript can show the difference:

javascript<br>// Stateful: the increment function keeps the state and refers to an inner variable<br>const increment = _ => (this.i = (this.i || 0) + 1);

// Stateless: the increment function does not keep any state and only calculates a new value<br>const increment = i => i + 1;

In the first example, the result depends on what happened before. Each call changes the internal value and affects the next result. In the second, the function is independent. It produces the same result for the same input, no matter how many times it runs.

Stateless code is easier to understand, easier to test, and easier to scale because every call stands on its own.

Testing and Debugging

When a program has no state, the only thing that affects its output is its input. This makes testing much simpler. By providing different arguments, you can easily observe how the function behaves and verify that it produces the correct results.

If you find a bug, reproducing it becomes straightforward. You can run the same function with the same inputs and see the same error every time. Once the problem is fixed, you can include that input in your test suite to ensure the bug never returns.

Stateless code builds confidence because it behaves consistently. There are no hidden variables or forgotten side effects. Every test tells you something reliable about how the system will behave in production.

Concurrency

Mutable state is one of the hardest problems in concurrent programming. When multiple threads or processes share data, each one can change it at any moment. This creates a constant risk of conflicts, unpredictable behavior, or even system failure.

If a program has no shared state, these problems disappear. There is nothing for threads to compete over. You no longer need to manage locks, barriers, or semaphores, and you do not have to worry about race conditions or deadlocks.

Removing mutable state turns concurrency from a complex problem into a manageable one. Each operation becomes independent, and the code becomes easier to reason about, test, and scale.

Scaling

When an application keeps no state, scaling becomes much easier. Each instance can handle requests independently, so you can add or remove servers whenever needed. The system does not rely on a single node to remember anything, which makes it flexible and resilient.

This principle is also what makes serverless architectures possible. In a serverless model, you provide functions that run in response to events. If one million events occur, the platform simply runs your function one million times. You do not need to manage servers, balance load, or worry about concurrency. You only pay for the time your code is running.

A stateless design allows systems to grow or shrink effortlessly. It lets developers focus on behavior instead of infrastructure and makes applications more adaptable to real-world demands.

Consensus

Consensus is a genuinely hard problem. The moment you have distributed state, you need multiple nodes to agree on what that state is. That means transactions, locks, and a whole lot of things that can go wrong in ways that are very hard to reproduce. You end up in two-phase commit hell, dealing with lock...