- 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 > https://github.com/Eventuria/gsd
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 ?)