Issue 49 - What exactly is "stateless"?!
What exactly is "stateless"?!
Another weekend, another weekend read, this time all about the question of what exactly is “stateless”
In this issue of The Weekend Read, we'll explore a concept that's frequently discussed in software engineering: Statelessness. While statelessness is widely recognized as a desirable property in the cloud-based world, an accurate and concise definition or mental model remains elusive.
Stateful and Stateless
The distinction between stateful and stateless seems straightforward. Intuitively, we associate stateful with an execution having state and stateless with an execution not having state. However, this simple definition leads us to a deeper question:
Can there be a (multi-step) execution without state?
Control State
We can think of an execution as an evaluation of an expression; in order to evaluate an expression, we divide the expression into a redex, a reducible expression, and a continuation, the rest of the expression.
So any (multi-step) execution is inherently stateful: At the very least, we need to remember what to do next, that is, we need to retain control state.
Beyond Control State
If an execution is inherently stateful, what does the term stateless execution denote? A common mental model characterizes a stateless execution as a "service that does not retain state between requests." However, this mental model is fuzzy at best, raising more questions than providing answers.
Now, there are many notions of executions, a host, able to receive a request, a guest, spawned in response to the request, responsible for processing the request, and a session, consisting of multiple requests.
Consider a web service, the host: Upon receiving a request, a thread, the guest, fetches relevant data from a database, processes the request, and persists any changes back to the database, after which the thread terminates. A session with a web service consists of multiple related requests. Think of an e-commerce application: we browse items, add items to a shopping cart, and eventually purchase the items.
Each execution is stateful, so which one is supposed to be stateless? Perhaps instead of asking "Is this execution stateless?" we should be asking "What is the strategy for managing the state of this execution?"
Conclusion
No non-trivial execution is stateless, computation is inherently involves state. When we talk about stateless, we are talking about moving some－decidedly not all－state from one stateful execution to another stateful execution at which point we arbitrarily denote the first execution as stateless.
Statelessness is better understood a choice about state management rather than the absence of state.
Happy Reading