Looking for some feedback on an idea that I’m calling “Partial Event Sourcing”.
Suppose you have some complex state S built from a stream of events of type E1 or E2. E1 are regular, persisted events like we are familiar with from event sourcing. E2 however, are not persistable (no serialisation function exists and the development effort involved in creating one is large).
Therefore, when the actor state S is recovered, it will be done from E1 events only and the state will not be the same.
Why am I thinking about this? I have a UI application in the 3D modelling domain where there are some very expensive and complicated objects in memory that support real time user interaction. These complex objects arrive as part of the state via non-serialisable E2 events. Note that this state cannot be re-hydrated during recovery because the computations take too long.
So the user views these complex objects in a UI, performs some action, and triggers the creation of an E1 event.
Some time later (after a system restart or other loss of the in memory state), the user wants to review what they did earlier. Since the state is only partially recovered from the E1 events, they will no be able to immediately resume from where they left off. However, the important part of their work will be saved.
If they really want to pick up where they left off, the user will have to manually re-trigger the expensive calculations leading to E2 events.
Clearly in a context like finance etc, the idea that you end up in a different state after recovery is madness. However I’m struggling to think why it’s objectively a bad idea. Is there any precedent for such a thing?
The closest thing I can think of is the fact that you have receive and receiveRecover as an acknowledgement that event processing behaviour can be different in real time mode vs recovery mode (e.g. duplicate events can be merged during recovery but not during real time mode). So why not take it a step further and accept that the state may be different after recovery?