There is no such thing as stateless

Every system has state*, even if it’s just the state of what I’m doing right now.

This fact is unavoidable in computer science. Of course, the concept of stateless programming is useful, and powerful to talk about. But requires some deep understanding of why and how to implement properly, to be useful. One cited reference for stateless programming is this blog on Functional Programming For The Rest of Us which includes the following:

It turns out that functional programs can keep state, except they don’t use variables to do it. They use functions instead. The state is kept in function parameters, on the stack

And this is my point. Stateless design is about rethinking state and storing it in a more appropriate place, not actually getting rid of it. From an information analysis point of view, stateless and stateful systems have the same quantity of information, except stateless ones tend to have less duplication, and better coupling.

A number of times, I’ve been told that some complex, slow, data processing system was “designed to be stateless”. This statement is often accompanied by “and we can’t change it, because it took us months to iron out all the failures”.

What this translates to is: the engineers didn’t want the hassle of setting up a database, so ignored the halting problem, and put all state in runtime-memory, hoping that nothing would ever go wrong. These systems then go live, and all the usual problems start to happen, but they remain in denial about the fact that their system has to know about what’s going on, and it can’t be just stored in memory, so a custom storage channel is invented (usually using file metadata coupled with complex heuristics) to store the information, while still pretending that there’s no state.

In this situation you end up relying on the implementer to design a custom database (yes, inferred information from file metadata is still a database, however hard it pretends not to be) to store their ‘stateless’ information. And this is actually a really hard thing to do correctly. Unless you design an ACID way to update the data, then you’ve just gained a whole new set of problems to solve. Which is why such systems tend to have a large set of failure scenarios that have to be coded around.

The point to the above rant is this. If you think your system is stateless, or think you can design your next solution to be stateless, consider the following questions:

These points lead to some common recommendations:

Comments and discussions welcomed.

— Steve

* If you know of some system that /is/ truly stateless, I’d be interested in knowing about it, but it probably doesn’t invalidate the point I’m trying to make here.



Tech Lead

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store