The fallacy of state recovery from
event storage
speaker: Jordi Martínez
Slide 2
Slide 2 text
Who am I?
Senior Software Engineer and Architect, currently at Dorna Sports
You may follow me at Twitter (@jmquarck), or my recent blog How Possible.
Slide 3
Slide 3 text
Events
Events are representations of facts.
Slide 4
Slide 4 text
Events
Events are representations of facts.
Facts are pieces of external reality. We may say facts are the atoms of truth.
Slide 5
Slide 5 text
Example: subscriptions
A UserSubscribed Event representing the fact of a particular User fulfilling the subscription
process in our UI.
Slide 6
Slide 6 text
Example: subscriptions
A UserSubscribed Event representing the fact of a particular User fulfilling the subscription
process in our UI.
These UserSubscribed events might trigger a Command to write a new line in a Schedule,
so that a fair warning email would be sent to that User once the current subscription
period is reaching its last day.
Eventually a Renew Subscription Command would run once the current subscription is
over and the User should be charged for a new subscription period.
Slide 7
Slide 7 text
Example: subscriptions
Actually, this is an example of how Events can trigger actions not only in the immediate
present, but also in the farther future.
Slide 8
Slide 8 text
State
And, what about State?
Slide 9
Slide 9 text
Local state
We may define a Local State as a summary of the values of some properties of Entities, or
Aggregates, inside a given bounded context at any particular moment in time.
There is no restriction on the list of properties to include in the definition of State, as well as
on the calculations we might run on them as part of the summary.
Slide 10
Slide 10 text
Example: inventory
The Inventory, defined as the economic value of all the Items we own, at any particular
date.
Slide 11
Slide 11 text
Example: inventory
For instance, we may talk about the local state Inventory at the 31d of December, 2017.
This state would look like a catalogue of all the Items we owned that day with at least
1 unit of stock, with their economic value at that moment (FIFO, Weighted Average Price),
in a particular currency.
Slide 12
Slide 12 text
Example: inventory
Item Units in stock Mean Acquisition Price Value
AB457 15 30,25€ 15x30,25€ = 453,75€
GL300-B 22 4,76€ 22x4,76€ = 104,72€
TR200 108 17,32€ 108x17,32€ = 1.870,56€
Inventory at 31d, December 2017: 2.429,03€
Slide 13
Slide 13 text
Example: inventory
Item Units in stock Mean Acquisition Price Value
AB457 15 30,25€ 453,75€
GL300-B 22 4,76€ 104,72€
TR200 108 17,32€ 1.870,56€
Inventory at 31d, December 2017: 2.429,03€
A detailed view of the State
Slide 14
Slide 14 text
Example: inventory
Item Units in stock Mean Acquisition Price Value
AB457 15 30,25€ 453,75€
GL300-B 22 4,76€ 104,72€
TR200 108 17,32€ 1.870,56€
Inventory at 31d, December 2017: 2.429,03€
A summarised view of the State: State summarised by an indicator
Slide 15
Slide 15 text
Local state
States are not snapshots, because the state stays the same for as long a period of time as
the values of the properties do not change.
Slide 16
Slide 16 text
Example: Customer state
Despite Local States, which spread over one bounded context, could we define a Global
State spreading throughout several bounded contexts of, say, Customers?
Let’s try with the asking some particularly interesting questions.
Slide 17
Slide 17 text
Example: Customer state
Is she profitable (at this particular moment in time)?
This means whether this particular Customer yield more revenue than the total cost we had to
spend with her up to this moment.
Slide 18
Slide 18 text
Example: Customer state
Is she active (at this particular moment in time)?
This means whether she completed at least one of the actions we decided are necessary for any
Customer to be labelled as Active.
Slide 19
Slide 19 text
Example: Customer state
Is she in debt (at this particular moment in time)?
This means whether she has standing out bills, no matter their expiration date.
Or, are we in debt with her (at this particular moment in time)?
This means whether there are item delivery pending from our side.
Slide 20
Slide 20 text
State recovery
Are those States, and any others alike, recoverable from an Event storage?
For instance, in the example of Inventory, is it possible to rewind our Event Storage to the
farthest moment in the past, and replay all the events related to Inventory from then on to
the 31d of December, 2017?
Slide 21
Slide 21 text
State recovery
Clearly yes, it is!
Provided every UnitReceived and UnitDispatched events were stored there, for every Item
in the Inventory.
Easy, right?
Slide 22
Slide 22 text
Local state recovery pitfalls
Well, not so, because Item events should have been implemented before the first unit of
stock ever arrived to our ownership (either by purchase, by us producing them, or from the
company founders).
Hardly likely, since Events are far more recent in inventory software implementations than
stock handling.
Slide 23
Slide 23 text
Local state recovery pitfalls
We might work around this unfortunate fact by introducing a special InitialStateEvent, or
similar, representing the actual Inventory at a particular date of our convenience, so that
Inventory recovery (rewind, replay) would be possible from that particular instant onwards.
To make its magic, this InitialStateEvent should be the very first one in the Event storage.
Slide 24
Slide 24 text
Local state recovery pitfalls
And, what if some units had been lost, or stolen, from the warehouse and we found it out
weeks later?
Companies are used to these corrections and carry on manual inventories regularly, as
well as other more sophisticated operations to ensure that the inventory value is right.
However, this corrections keep their date, hence the wrong State often stays as it was.
Slide 25
Slide 25 text
The fallacy exposed
So, the fundamental truth is worse: States stand for a representation of reality as we knew
it was at a particular moment in time, but not what we now know it was at the same
particular moment in time.
Slide 26
Slide 26 text
Options to cut the Gordian knot
Could we imagine ways to circumvent the fallacy?
I bring two suggestions:
Retroactive fact representation by dispatching bespoke corrective Events.
Event transformation on replay time.
Slide 27
Slide 27 text
Tactic 1: retroactive recovery
This tactic stands for storing brand-new Events to represent past facts we know now, but
that were not known at the time.
In other words, we are dispatching Events now that represent facts in the past so that past
States may be recoverable now.
Slide 28
Slide 28 text
Tactic 1: retroactive recovery
From an operative point of view, for this recovery to work State calculation procedure
must spread throughout the whole Event storage, no matter what moment in the past the
State pinpoints to.
Slide 29
Slide 29 text
Tactic 1: retroactive recovery
Should we store these Events in the same Event storage, or, to keep this latter's purity, store
them in a separated Event storage (a Complimentary, Retrospective Event Storage)?
Actually, this separated event storage would make that false retrospective events
operatively easier to pick when needed, since this would have likely a far smaller size.
Slide 30
Slide 30 text
Tactic 2: event transformation on replay
Since we are recovering States, not Events, we might plug in an intermediary service
between the Event storage and the State producer which transforms their payload to
either calculate new properties, or modify the values of others. Some call this operation
upcasting, for it was invented to handle Event schema evolution.
We might even complicate further this transformation with combination of several Events
in one via the common algebra operations (union, intersection, disjunction, etc.)
Slide 31
Slide 31 text
TL;TR
Events represent facts.
States summarise knowledge of the Domain in a particular moment in time, by a selected
gathering of Events from the Event storage.
But State production from Events can only represent the knowledge we stored until that
particular moment in time. Further facts relevant to that State might arise later on, so that
we should either abandon States, for misleading, or add this new information to the one
provided by the Events in the store somehow.
We have seen two possible tactics to achieve this: dispatch of corrective Events, and
transformation after recovery.
Slide 32
Slide 32 text
Thanks!
I am eager to keep talking about this now, and further.
Thanks for your attention, patience, and feedback.