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

How does Axon work with State Stored Aggregate, Database Transaction, Message Dispatching, and Message Storing? What happens in case of a failure between these operations? Is there some kind of inbox and outbox mechanism?



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.


Hi @Murilo_Carlos_Cardos,

in order to solve this we have introduced a local event store which persists all the events within a local transaction first.

Then there is a component which picks up the events and publishes them to the global event store.

The idea is similar to the outbox pattern.

Nevertheless, there is no support from Axon Framework itself (so far).

To be honest, we decided to move away from State-Stored aggregates to Event-sourced aggregates as it offers more advantages compared to the slightly increased efforts.


1 Like

Hi @Oliver_Libutzki,
Thanks for sharing your experience.
Your case confirms my point. What type/category of software do you work on?

@moderators Would you have something to add or clarify? Huge thanks!

Hi @admins
Do you have something to add about it?
Thanks! :slight_smile:

Is there a reason to not have a local event store with all events?

We currently have a global event store (in house design with which I’m involved), but we’re considering converting the event store to a module that can be integrated to avoid the outbox pattern that we’re using.

So we are currently thinking of moving the event store to the same database, and having consumers contact the service producing those events directly to get an event stream. This will introduce additional load on the producing service, but our thinking is that if this becomes a problem we could always consume all events in a replication service which can then serve these to other consumers.