State-Management in general
What I am going to describe in this chapter is about State-Management in general. I am deliberately leaving out a technical solution.
Let's think about a couple of scenarios that come to our mind when think about states.
We must keep the received data in its original form in order to be able to refer to the received record at any time: payload.
Of course, the payload has a payload-type.
We must be able to reference the received records in the source system and we expect that each received record comes with a unique identifier from the source system.
The userId contains the source system record id.
When a state-record has been created systems must be able to access the state record using a unique identifier.
The id is a unique id for each state (requestId).
Normally, different customers send data from different sources, using several channels and we must track the origin of each state-record.
The generic context is used to track the records origin.
It is probably a good idea to give a state some kind of name that contains information about which (business) state is involved.
A key is a well defined name/key for each state.
Keys can contain namespaces, like: CustomerA.Offer to indicate that this state is an offer from customer A.
Last but not least, we want to track a state.
userState contains the state of the record, and
userInfo can contain any user-defined (error) message for the current state. The userInfo may contain a simple text message, as well as a structured, additional information, like a JSON record, to track additional metadata for each state. This field is always custom and its information is fully transparent for the state-management.
More considerations
Further considerations, not detailed here, could be:
state-lifetime -> expiration date
track a records state history
Last updated