These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
Hi, @krasserm. I'm revisiting something I was trying to do with Eventuate half a year ago and it seems to me that the full-blown event sourcing architecture is not suitable for my task.
The problem is that my write model (the one I should validate commands against) is a graph. It's complex and I can't represent it as case classes in actor's internal state. I need to perform graph traversal, index searches, etc to validate commands. And even if I could represent (in-memory Neo4j) it I would end up with whole user data in memory.
Alternative simplified (or not so) architecture I'm thinking of is getting rid of commands validation at all. Every command would just produce some events and let the external read model (graph database) writing process be responsible for validation. For example, if I'm processing the
CreateTreeNode(parentId: Id, ...) command, I would produce
TreeNodeCreatedEvent(parentId: Id, ...) and return a specific error code from the DB facing API if
parentId does not exist. On event replay of course I would re-try such failed commands but that's not a problem. I would like to handle only application-specific errors, like NotFound, Conflict, etc and let infrastructure errors (like db not available) to re-try failed events.
But I need also to react on application-level events processing failures, if I've got NotFound error code I need to notify the initial command sender about it. Here is the problem: I can't create new commands from events handlers, right? But what if I could? Of course I would need to not create 'em on events replay, not sure how to ensure that.
Could you leave some your thoughts/suggestions about the problem I have here? I would like to re-use some great Eventuate features like replication, events persisting and still be able to adapt it to an architecture I could be comfortable with. Thanks!
ConfirmedDeliveryfor this as with this you can ensure that your command does not get lost and is not re-delivered on replay if successful delivery is confirmed. But depending on your requirements you could also explicitly check with
ConfirmedDelivary, right? Would be also cool not to replicate failed events but that's too late at that point.