Axon Framework Relibality and Scalability

I’m working on a new software package in the financial industry, and we are evaluating Axon as a possible framework. The technology stack we intend to use includes spring boot and mongodb. Because of the nature of our software we need to be able to guarantee all events be properly stored in the database and that events make it to all appropriate handlers. My impression is that using mongodb for the event store does not allow us to guarantee event writes that originate from a single command but may span different aggregate root types (think of a money transfer use case). Is this a correct assessment? Is there any place in the framework where changes could be made to do a two phase commit to all events for a unit of work?

My second question has to do with scalability. I didn’t see any issues with the Distributed Command Bus, but on the event handling side there seems to be a bottleneck. My impression is that all events must be handled by one and only one instance of an event handler. Is there any way to distribute that processing across more than one JVM?

Are there any other issues that will need to be address like specific configurations for the event bus that are necessary to guarantee a hardened system?

Thanks,

Jacob Ring

Hi Jacob,

Axon uses the UnitOfWork to coordinate the process of storing and publishing messages. It is possible to connect a transaction to this UnitOfWork, which ensures that either both, or none of these actions are performed. However, even with a two-phase commit, there is never, ever a guarantee that either both or none are executed in case of system failure.
Furthermore, MongoDB doesn’t support transactions. It can only update atomically (and isolated) within a single document. So here, any transaction manager (two phase commit or not) isn’t going to help.

I don’t really understand the question “My impression is that using mongodb for the event store does not allow us to guarantee event writes that originate from a single command but may span different aggregate root types (think of a money transfer use case)”. Commands that span multiple Aggregates are a code/architecture smell. The aggregate is a consistency boundary, so the requirement to load two of them within a single transaction, is at least an indication that the aggregate boundaries should be revised.

“My impression is that all events must be handled by one and only one instance of an event handler. Is there any way to distribute that processing across more than one JVM?”
That’s actually not the case. You can use -for example- AMQP to publish events between JVM’s. However, what you probably do want to guarantee, is that certain event handlers that are distributed only have one instance handling each event. However, in some cases they could compete for messages of a specific queue, while for others, you need to only have one active consumer at any time.

One thing to note is that the semantics of publishing events will slightly change in Axon 3. In Axon 3, the Event Store will also act as the mechanism to publish events to the handlers. This will help in guaranteeing publication of all messages to all (required) components. It will also simplify the infrastructure for distributed implementations. We hope to deliver Axon 3 in Q1 of 2016.

Hope this helps.
Cheers,

Allard