How to we ensure our event handler is idempotent? Do we need to store the last event version in a separate database, and perform our sql queries in a transaction, updating our read model, and also our last event id?
There's a lot of paths. Sometimes, you can just get away with every mutation inserting or updating specific values and the result is that any event that comes in, you can project into the data set in a way that isn't sequence-specific. Another way is to store data for each mutation that comes in, and compare the values that have already come in before updates. Etc. I personally don't have one right way or right answer. I've seen a number of patterns work for different teams.
@@ShawnMcCool Would you capture a UUID for each event that is raised. Handlers can then use this for idempotency. This is a path that I have followed but not in an event sourced system and wondering if you think it is applicable. There is also concurrent processing of events. Borrowing from message brokers I assume that the aggregate ID can be used as a message group to partition processing. I am thinking about external systems or adjacent applications responding to these events e.g. when the order is completed that triggers the creation of a fulfillment process or an order fulfillment aggregate. But the fulfillment system has responded to the order aggregate domain event. I realise this is tangental to event sourcing.
@@Ffaarg7 yes this all makes sense. We tend to try to find an idempotency mechanism that doesn't require extra state storage. But if not possible then event id is useful. We use mutex locks on state changes to prevent concurrent processing.
Awesome, thanks a lot!
How to we ensure our event handler is idempotent?
Do we need to store the last event version in a separate database, and perform our sql queries in a transaction, updating our read model, and also our last event id?
There's a lot of paths. Sometimes, you can just get away with every mutation inserting or updating specific values and the result is that any event that comes in, you can project into the data set in a way that isn't sequence-specific.
Another way is to store data for each mutation that comes in, and compare the values that have already come in before updates. Etc.
I personally don't have one right way or right answer. I've seen a number of patterns work for different teams.
@@ShawnMcCool Would you capture a UUID for each event that is raised. Handlers can then use this for idempotency. This is a path that I have followed but not in an event sourced system and wondering if you think it is applicable. There is also concurrent processing of events. Borrowing from message brokers I assume that the aggregate ID can be used as a message group to partition processing. I am thinking about external systems or adjacent applications responding to these events e.g. when the order is completed that triggers the creation of a fulfillment process or an order fulfillment aggregate. But the fulfillment system has responded to the order aggregate domain event. I realise this is tangental to event sourcing.
@@Ffaarg7 yes this all makes sense. We tend to try to find an idempotency mechanism that doesn't require extra state storage. But if not possible then event id is useful. We use mutex locks on state changes to prevent concurrent processing.