Configure Axon Server to function without event store

Axon Server
1

We’re upgrading our Axon 2.1.2 application to Axon 4.3.2.

For some customers of our application we have configured Axon to function without an event store. We’ve configured it as follows:

    <axon:jpa-repository
            id="chargingStationEventRepository"
            aggregate-type="com.test.OurAggregate" />

    <axon:aggregate-command-handler aggregate-type="com.test.OurAggregate"
                                    repository="chargingStationEventRepository"
                                    command-bus="commandBus”/>

We’re looking to configure Axon Server to function without an event store as well. Is this possible and if so: how?

2

Awesome to hear you are making the shift from Axon Framework 2 to 4! I am confident the upgrade will bring you a suit of new additional features and enhancements you can base your application on. :slight_smile:

Interesting to hear that some of your clients aren’t using the Event Store here. Does that in your scenario also mean they are not publishing/using any event messages? And, I assume they still have aggregates in their application too. Does that mean those aggregates are not event sourced, but use the state-stored solution instead?

Knowing those extra bits I’ve just requested might change my answer slightly. So it would be valuable if you could post those in an upcoming reply. For now though, let’s move over to your question on how to configure Axon Server to not be an Event Store.

When it comes to running Axon Server, there is no real means to tell it not to be an Event Store. So essentially, it will always build up the required components to this end to fulfill both the Messaging Platform and Event Storage requirements. Hence, the configuration lies within the client (read: the Axon Framework application) to not use the (auto) configured Axon Server Event Store, but replace it by your own solution. This is where my questions become important, as it is currently not 100% obvious to me whether events are at all being used.

If they are, you will still require the usage of an EventBus, for which I would recommend the SimpleEventBus. Configuring can roughly go two ways:

  1. By providing a SimpleEventBus in a Spring Boot environment, it will automatically replace any other auto configured beans, like the Axon Server Event Store.
  2. Through Axon’s Configurer you can use the configureEventBus.

Furthermore, you might or might not be running this application you are describing in a distributed environment, thus I mean you have several Axon applications talking to one another through commands, events and queries. This is were you might hit a roadblock at the moment, as Axon Server can only serve the purpose of distributing events if it is also an Event Store. Hence by not using it is an Event Store, you will loose the possibility to distributed event messages between application. You would thus be required to configure the AMQP Extension for example to be able to achieve this again.

Long story short, you have to configure a SimpleEventBus as the event bus used in your application and you are done. Whether this is sufficient in your scenario however depends on a more fine grained explanation of your application.

Regardless, I hope this helps!

3

Thanks for your elaborate answer.

Does that in your scenario also mean they are not publishing/using any event messages? And, I assume they still have aggregates in their application too.

They are using events and aggregates. They are not interested in old events, and don’t want to backup/restore data they’re not interested in.

Axon is providing the command and event functionality where one command results in an event that is used by multiple other modules. We can configure those modules to be in the same Spring Boot application or entirely separate Spring Boot applications.

Looking at your answer I think that in the first case (all modules that listen to events run in the same application) we should be fine by using the SimpleEventBus, while still using Axon Server.

If they run as separate applications we have to use the AMQP extension so they can reach each other without using Axon Server at all, as there is no option to disable the event store in Axon Server when using a distributed setup.

Is that correct?

Edit:
If we could configure Axon Server to delete old events after x hours/days while using snapshots to keep the Aggregate state that would be a good alternative as well.

4

First off, sorry for the long pause here @Mark. Somehow lost your response in plain sight…
To not waste more time, let’s go back to your response:

Is that correct?

Yes, that assumption is indeed correct. Using the SimpleEventBus, or the AMQP Extension, will however also mean you cannot make use of the TrackingEventProcessor (TEP). The EventProcessor in Axon 3 and 4 takes up the space of what’s called the (if I recall correctly) “Cluster” in Axon 2. Furthermore, the helpful functionality like replaying, handling from a point in time or multi threaded are only capable if you would use a TrackingEventProcessor. Reasoning why you cannot use the TEP if those clients would opt for a SimpleEventBus/AMQP Extension solution, is because neither are solution which allow streaming of events. They resemble simple queues/buses which loose their events, which simply don’t support streaming of events from any point in time. For that, a store is a simple necessity.

So, although fully capable, I’d make it clear with your clients that any freedom to adjust any of their models (both command and query side) are completely lost if they do not store their events. Hence, they/your team would need to resort to maintaining several sources of truth (namely all your models). I am not here to say that’s not doable, mainly providing a warning of the downsides of not maintaining your events.

If we could configure Axon Server to delete old events after x hours/days while using snapshots to keep the Aggregate state that would be a good alternative as well.

As Axon Server aims to be an Event Store, thus storing events until the end of time, there is no means to define a retention period on those events. However there is of course nobody stopping your from removing the files yourself. If you would go that route, know that Axon Server has a segmented based event storage solution, on disk, which default to a size of 256MB. Depending on the size of your events, that would mean anything between 750_000 to 250_000 events. If a more granular approach to removal is needed, the segment size of those events can be adjusted.

Hoping this provides you the additional insights to look into this further @Mark!
And again, my apologies for the long pause in reply.