3

I just stumbled upon an article by Lucas Majerowicz titled "Add git-like functionality to your application using Event Sourcing".

In it, he describes using Event Sourcing with events stored as nodes in a graph database (he uses Neo4j). In so doing, it becomes trivial to branch the event store from arbitrary events in order to maintain multiple application states simultaneously (and indeed then to merge events from one branch onto another).

I'm surprised that I can find relatively little else written about this approach, as it seems like a pretty useful idea. Indeed, most of the literature on Event Sourcing that I can find appears to share my own assumption until now, that the event store is effectively a linear stream of events. (Of course, one could still achieve the same branching effect in such a linear stream by including in each event the identifier of its "predecessor event"—but it would be far more costly to reconstruct application state using such a structure).

Is this approach (an instance of) what Martin Fowler is describing when he talks about Parallel Models? It certainly appears to be at a high level, but then I can't see him getting anywhere close to describing a system that branches application state so freely.

Something about this is nagging at me, that Event Sourcing should be a pure stream of events. Then again, it's precisely this sort of flexibility that makes Event Sourcing so powerful—yet it's surprising that so few event stores use graph databases in this way.

Am I getting myself in a twist over nothing?

  • Just a follow-up thought: where should an event be appended, if it is orthogonal to the branching? Arguably it would need to be appended to all branches... – eggyal Nov 27 '17 at 23:24
  • Ubiquity doesn't make an idea good. The ability to solve a problem in a unique, creative or especially useful way is what makes an idea a good one. If popularity were the basis for all decisions, we'd still believe that the earth is flat. – Robert Harvey Nov 27 '17 at 23:35
  • @RobertHarvey: Indeed. But then maybe experience also brings knowledge of pitfalls... – eggyal Nov 27 '17 at 23:37
  • I took a look at the article you linked, and it strikes me as a rather flexible implementation of the Actor Pattern. While the Actor Pattern is a very useful thing, not all applications require it. – Robert Harvey Nov 27 '17 at 23:39
  • 1
    If this is solving a problem for you, go for it. Easily supporting branching histories is one of the benefits of immutability. On the other hand, many applications don't really need this functionality, and it will cost something in performance and complexity. Practical constraints may make it infeasible even if it is conceptually desirable. For example, if you allow freely switching between "histories", it may require a lot of memory to keep read-optimized views of all possibly "histories" so you can hit latency goals as the sharing may be lost in those representations. – Derek Elkins Nov 28 '17 at 5:43
1

Actually branches are reasonably common.

Look at EventStore and the event type $linkTo this is a use case for it! Basically you can have many steams linking back to an event in different ways/orders.

I also discuss some patterns doing similar things in discussing stream/event versioning patterns in the versioning book https://leanpub.com/esversioning

1

I think your gut feel is right.

Consider rebuilding the object in such a tree. when you come to a branch which one do you take? What about snapshotting to reduce disk space?

I'm going to go out on a limb and say that Eventsourcing is primarily used to solve the problem of atomic transactions in distributed systems.

Branching doesn't help you here, in fact it exactly what you are trying to avoid.

So yes, cool idea but maybe needs a new name to distinguish it from 'Event sourcing as we know it'?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.