Stateless story
A stateless story
Once upon a time there were external consultants who were in the mood of creating/having one of these cool new stateless services that scale so perfectly. This was about 2005-ish, so this was really something cool at that time.
Hence, the question raised, as a service client, why we can’t call the The Product WebService in a stateless manner? I mean, who needs all these SessionIDs? We have to store them, to keep track of them, open and close a session … oh my! And stateless scales sooo much better, just think of it!
We then replied, that we see the point (we really do) but The Product is a complex product and having it fully stateless would require to carry a lot of data around. The real truth is, that not too many things really work stateless.
Let’s just have a small example: A simple Google search. As the input values, you have the search term that defines the results you get. Oh, things like geolocation, language, and some other settings may also affect the result, of course. But basically that’s it. So you get your search result.
Now you want to see page 2. I have no idea what happens behind the scenes exactly but it is very likely that Google just does the same search again and just returns a different result slice. Maybe they store the last search somewhere for some amount of time, but given the time it takes to just redo a search I would doubt that. Either way, what essentially happens here is that the system reconstructs the search result somehow and performs an operation on it.
Remember, the only time when you really entered the search term was at the beginning, but for page 2 you only gave the information about the page number as an input value. So how does the system know what the search term was or (if so) where the search result could be stored? Because we have the browser who holds some state data for us: Either the search term itself, or at least some token that gives access to the previous search result, and whatever else may be needed.
Lesson here is: There is always a state in any system that needs to carry our actions that depend on the result of previous actions. The only variable that we can change is where we place it in the whole system and how we make sure that all involved components do have access to it. It can be hidden in a database, or as an extreme form it can be written down onto a sheet of paper and manually re-entered by the user, but it does not just vanish.
There are a lot of reasons why a system like The Product or any other complex business system is different compared to a Google search. One of which is that it is somewhat more complex to adjust, configure and recalculate a large set of highly dependent and interwoven variables depending on other factors that are just on the fly determined during the process itself. Google surely did a great job at setting up all of these clusters processing tons of queries and running through highly optimized data that span multiple storage servers – all for that single purpose of efficiently finding your small search terms in all the sites known to the system. But at the end they have only one real input value: Your search term, and there is not much dependencies between two web sites A and B that happen to contain the search term, they're just completely independent of each other. In The Product, the selection of one component may restrict another component, one user choice may invalidate or conflict with another, and so on, which adds another layer of complexity.
So in order to achieve the same thing with The Product or any other system of a certain data complexity, we would have to carry a lot more data around to be able to reproduce the exact logical environment for some action that should be executed without having to go through all of these costly calculations again and again when the user wants to change just a small configuration option but keep the result of all previous configuration steps intact. And in order to prevent us from the necessity to shovel around large data buckets that carry the state that we pretend does not exist back and forth, wasting network bandwidth, CPU and memory on the way, we used the concept of sessions. And the magic key that grants you access to all these data is on small data item: the SessionID.
Long story short: No matter where and how to store it - there is always some state data that need to live somewhere. By throwing them out of one process or one machine, the responsibility of keeping the state is only handed over to some other entity in the chain. It does not vanish, it only moves.
So we told them, that this is not the way how The Product works and we don’t think that this is the way to go and we believe that we are going to make a mistake.
Well, it turned out that some people are more clever than others and after some back and forth we finally said to ourselves: Maybe these high-paid consultants see something we don’t see. Let’s just give them the option they want, they deserve a fair chance to convince us. Maybe we can even learn something. Wouldn't that be great?
Unfortunately, they were not able to do that. After doing the initial request, the stateless server was not able to deliver any product details in the second call because it just forgot the search result including any of the configurations previously made and had no idea what the second call was all about.
And that's how The Product became stateful again. The option still exists as kind of a reminder, but one should not really use it for serious business.