Hi,
If our domain uses the traditional ORM over RDBMS to back it and we want to fire off an event to EventStore after a change in the domain, how do we deal with failures? I know if we resend the event with the same id then the event wont get persisted twice, but what is the recommended way of even sending the event again if say the RDBMS got written but the event didn’t arrive? Do we have to keep a representation of the event in the RDBMS written in same transaction as the table write, to enable us to recover and resend if things go down?
Cheers,
Chris
What are you using Event Store for in this case?
As far as Event Store goes as long as your are utilising the idempotent nature of the event writes, that takes care of the Event Store side. However when it comes to dealing with failures in your case it would depend on what you are using Event Store for.
We would be using event store mainly as a delivery mechanism of events to downstream services. We wouldn’t be using events in eventstore for state rehydration of the aggregates that are publishing those events, that state would be stored “traditionally” in RDBMS via ORM
There are a couple of options here.
1) You can wrap them in a distributed transaction (highly not
recommended). There is an example of this laying around somewhere.
2) You can write events into rdbms (imagine a table called queue) and
read from there to send into eventstore