Using Axon on Amazon Web Services - Command bus implementation

My project team is currently assessing the suitablity of using Axon for our application, which is deployed on the Amazon Web Services platform. We have string requirements to use AWS functionality where possible, including services such as Simple Queue Service (SQS), Simple Notification Service (SNS) and DyanmoDB for persistence. This has numerous challenges, as the characteristics of resources to support Axon (network messaging, message queues, persistence stores) provided by AWS are different to what you might normally expect.

A particular area of concern is implementing a distributed command bus. Unfortunately we don’t have the option of using JGroups and so cannot use JGroupsConnector. It would be possible to dispatch commands to an SQS queue, and have subscribers consume messages from the queue, but we then lose Axon’s capability of routing commands to a given segment (consumer), where the routing strategy is not random e.g. based on aggregate ID. (Each consumer is on a different machine)

My question is does Axon depend on the routing behviour of commands? Assume here that if 2 machines process commands for the same aggregate instance, the conflict is detected by an optimistic locking check when writing to persistence.


Hi Steffan,

just wondering, why isn’t the JGroups Connector an option for you? Technically, it works fine on Amazon with a Gossip router or a static list of members. Multicast discovery doesn’t work there.

Routing commands using a Queue works, but has disadvantages. Command handling works best when commands for the same aggregate are routed to the same machine. Failure to do so makes caching of aggregates inefficient and you will get a lot of concurrency failures on the Event Store (provided that the Event Store is able to detect them). So everything will work, but concurrent access will cause inefficiencies. If you go down this route, make sure to retry commands that failed with a ConcurrencyException.