The fallacy of state recovery from event storage speaker: Jordi Martínez 

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. 

Events š Events are representations of facts. 

Events š Events are representations of facts. š Facts are pieces of external reality. We may say facts are the atoms of truth. 

Example: subscriptions š A UserSubscribed Event representing the fact of a particular User fulfilling the subscription process in our UI. 

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. 

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. 

State š And, what about State? 

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. 

Example: inventory š The Inventory, defined as the economic value of all the Items we own, at any particular date. 

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. 

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€ 

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 

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 

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. 

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. 

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. 

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. 

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. 

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? 

State recovery š Clearly yes, it is! š Provided every UnitReceived and UnitDispatched events were stored there, for every Item in the Inventory. š Easy, right? 

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. 

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. 

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. 

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. 

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. 

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. 

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. 

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. 

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.) 

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. 

Thanks! š I am eager to keep talking about this now, and further. š Thanks for your attention, patience, and feedback.