Axon trader is still an single-JVM solution, but we will start migrating
that to Axon 2.0 shortly. We can only start that when the Axon 2.0 API is
completely final. The idea is to base the migration guide on the findings
we have there.
The distributed command bus is as good as finished. It can use Jgroups to
dynamically connect and distribute command across members. That means that
when a member drops, its share of the load is distributed over the
On the Event Bus side, I am working on AMQP connectors. At a client, where
I am helping out with scaling their application, I noticed that using
Spring AMQP provides a lot of features that deal with resilience, such as
automatically reconnecting when a connection is lost. So the first solution
will probably build on that. You can always use the Spring Integration
connectors (that have been around since the early Axon days) to connect
with other protocols.
The use case you describe can be easily achieved by setting up a
distributed command bus on each Tomcat node, with a SimpleEventBus to
dispatch events locally. The distributed Command Bus will ensure that
commands are consistently routed across available members. The
SimpleEventBus will ensure that Event Handling (and thus query database
update) is done in consistently and in the same transaction. You can use a
single (clustered) database behind the machines.
Note that the consistency requirement puts the bottleneck in the database.
If you don't need your QueryDB to be absolutely consistent, you can use an
asynchronous events bus, such as the ClusteringEventBus with an AMQP
Hope this helps,