Great to hear that you’re considering Axon. You’re right, AWS Dynamo/SQS is at the moment not supported directly by Axon at this point - some more technical details on that later.
First of all, I’d like to comment on more fundamental issue: you’re talking about reading events “to rebuild the application state”. That sounds like you’re planning on using event sourcing as pattern. Axon Framework is very well suited for that. You would see state being event sourced in two ways:
- The actual aggregates processing commands would only store their state as a series of events. This is what I would consider “true” event sourcing because events would be primary storage. This way of event sourcing is not mandated by Axon, but it is in a certain sense the default and it is used by a large majority of users.
- Read-side/query models can be populated using events raised by aggregates in command handling or somewhere else.
Now, “using Axon just as a CommandBus/EventBus framework”, ignoring the storage of events momentarily, will work if you’re satisfied with doing (2) without doing (1). If you want to do (1), you’ll need a way to store and send events from the beginning. I’d definitely recommend doing (1) and (2) together. Ultimately, it’s the easiest approach. If you’re doing (1), then by definition you will have events covering everything that happens and (2) will be easy.
To run Axon (both (1) and (2)) on Dynamo/SQS could potentially be achieved by creating custom implementations of the EventStore, CommandBus and QueryBus interfaces, but you would face quite a few challenges. To mention just one: SQS standard queus don’t offer an ordering guarantee, which is a very bad match with event sourcing! (Imaging a ‘OrderCreatedEvent’ and ‘ItemAddedToOrderEvent’ being delivered out-of-order). Now, SQS does alternatively offer FIFO queues, but they’re not available in all regions and have throughput limitations.
I think you have some options that would make for an easier, more scalable setup on AWS:
- You could use AxonHub and AxonDB to get a very easy to maintain, highly scalable Axon infrastructure. This could run on Amazon EC2 instances, but also works great with Kubernetes, which will soon be supported natively on AWS (currently available in preview). Kubernetes in general is a great match with a scalable Axon application.
- Using an AWS RDS database as an EventStore will work as well. Axon’s tracking event processors would be actively reading events from there by doing polling for new events.
Hope this is useful - happy to discuss this further in a call or something if you want.