Need for transaction mechanism spanning over multiple streams when implementing Command Sourcing pattern?


  • Context :
    I took 6 months of my life to develop my skills in Haskell …

So I decided to implement a “todo list kind of app” using a CQRS architecture, and I have added command sourcing on top of it…

Coding in FP went really well and if you are interested to see some code in Haskell + CQRS using the EventStore >

  • Challenges

So, In the Event Sourcing world, I was having synchronous Commands :

  • it reads previous events persisted (with snapshot or not) and get the write model

      - it processes the command based on that write model 
      - it produces a batch of events > save that batch in the EventStore in one shot
      - Done.

if the eventStore service gets down, then the Command fails and the client handles that failure somehow.

Now in the command sourcing world…

  • The client sends a command and it’s persisted by aggregate, waiting to be process…

      - Same way as for Event Sourcing, it reads the previous events persisted (with snapshot or not) and get the write model
      - One by One they are consumed and It produces the following artefacts :
  • Batch of Events

               - Command Response (Accepted or Rejected)

…That’s where I have some issues …

if the eventStore service gets down between saving the batch of events and saving the command response ? What can I do ?

Do I need a mechanism of transaction spanning over multiple streams ? (which to my knowledge, the eventStore does not have ?)