It has come to my knowledge, that in the last post in the “breaking the monolith” series failed to clarify the shift needed when moving from a statefull (usually object-oriented) design to a stateless (usually event-driven) system.
As you probably already know very well, as workers in the information industry we dabble in the fickle trade of moving, storing, and manipulating information (either into other types of information or into actions). We also like to call it “data”, so we would feel smarter (and cool) and other people would think that what we do is extremely complicated and hard. Let me assure you, it is neither.
What is extremely complicated and hard is being able to keep track of a large organizational data (information!) state. This is another one of those tasks that is unbearably difficult for humans to perform and laughingly easy for computers to do repeatedly. Our job (and that is the last of my obvious statements for today) is to translate the real world challenges and problems into resolvable states of the system.
Considering that, it is not trivial to understand the industry’s rush to move away from the idea of state. True. In fact, this is mostly a technical move, changing the way we note state and not whether it s being noted or not. And with this (hopefully) better understanding of the problem we are facing, we return to the question at hand: in what way is the state of the system is being noted if our system is completely “stateless”?
This question revels a basic common misunderstanding of the design of event-driven (or any other kind of stateless) systems. No computation system as a whole could be completely stateless. Even the mere calculator has an initial state, simple as it may be. In event-driven systems we separate computation from data – so all the compute elements are stateless, but the data-store will always be statefull (it is a conflict for it not to be).
And so we see, that the state of the system, which is of course a model of some process in the real world, is independent of the actions (or computations) that may be applied to it, this is the “stateless” part. This sheds light on one half of the picture, but exposes another problem of its own – which is another the second part of the state: Which action will be performed on a specific piece of data, and when?
We can resolve this by returning to our basic mapping of the (business) need the system is build to answer. This part of the state is stored in the topology of all the compute elements, in the way they connect to each other and most important, in the data flow through the system. The complex structure of queues and processes we call the topology is the other side of the coin when looking for a state in an event-driven system. The position of a single event in the flow is just as part of it’s state as the information it carries. In order to transform a design of a state full system it is crucial for us to separate the system to the simplest compute elements and data stores we can, and connect them into a topology that could accommodate the flow of these events in a way that is meaningful to the problem we are trying to solve.