State Stored Aggregate, Database Transaction, Message Dispatching, and Message Storing

Hi,

I found this forum topic The outbox pattern which ends up in an issue Consistency gap in conjunction with state-stored aggregates · Issue #1103 · AxonFramework/AxonFramework · GitHub.

Please don’t get me wrong but I can’t see why this is not a priority. I’ll try to explain the reason:

In a “traditional” approach we have database transactions that allow us to change multiples entities/aggregates with the price of long blocking time and high memory consumption. Reads and writes are done in the same database too what makes everything even harder.
At some point in time, the application cannot handle all the requests using this architecture. So as most specialists recommend instead of switching straight to event sourcing we could split the application into reads and writes and make communication between entities/aggregates through events. But, because of the open issue, in my point of view, this is not an option. We can end up in a real inconsistency state which it’s not possible to recover unless finding the broken pieces and fix them manually but if we’ve moved to this architecture it means that the scale does not permit fix them manually. Imagine a stock management system or an accounting system in the cloud with multiple customers…

If I’m wrong, please help me see it.

Thanks!