I really liked the modular monolith approach using Events and Listeners, but I had a practical question about atomicity.
When a module creates or updates a record (for example, a Grade) and dispatches an event for other modules to react to, how do you handle scenarios where the listener’s processing needs to be atomic with the main operation? In other words, if a listener in another module fails, how do you ensure that everything is rolled back, since different modules are participating in the same business flow?
PK
Povilas Korop
✓ Link copied!
Great question!
I'm off computer and can't easily try, but I think if you start DB Transaction in one modjle and call event INSIDE of that transaction, and then listener in another module doesn't use ShouldQueue, then it should be executed in the same transaction. So if some exception happens in listener, whole transaction should be rolled back.
I really liked the modular monolith approach using Events and Listeners, but I had a practical question about atomicity.
When a module creates or updates a record (for example, a Grade) and dispatches an event for other modules to react to, how do you handle scenarios where the listener’s processing needs to be atomic with the main operation? In other words, if a listener in another module fails, how do you ensure that everything is rolled back, since different modules are participating in the same business flow?
Great question!
I'm off computer and can't easily try, but I think if you start DB Transaction in one modjle and call event INSIDE of that transaction, and then listener in another module doesn't use ShouldQueue, then it should be executed in the same transaction. So if some exception happens in listener, whole transaction should be rolled back.
But please try it, I'm not 100% sure.