In Axon's 10 year history (you’ve read that right, it turned 10 in January 2020!) we have striven to take all received feedback to keep improving the look and feel. Not only usability for developers has been a main spear point, but the performance and flexibility of Axon was greatly influenced by what you and other users told us.


In October 2018 the AxonIQ team released “Axon 4” combining Axon Framework with Axon Server, to further enhance developers to build applications based on these concepts. The main drive to release Axon 4? To improve the developer’s ability to focus on the business functionality of their application, whilst providing even more handles to address non-functional requirements their application requires. As shared earlier a great deal of these enhancements would not have been possible were it not for your input. All combined we feel that Axon 4 provides the most straightforward solution to building business agile applications.


Although Axon 4 is over a year old, we still notice a great many usages of our previous major release. There is inherently nothing wrong with that of course, Axon 3 is a fine framework on its own. Regardless, any users of Axon 3 will be missing out on all the new features and enhancements all contributors have worked so hard on.


So, why not migrate from Axon 3 to Axon 4? We know that upgrading is typically a lot easier said than done. Especially from the product creators of course. Hence there should be clear advantages for you and your team to endeavor on an Axon 3 to 4 migration. Let alone to find the leverage to convince your business funding the work! It is this exact leverage which I would like to share with you. It is a summary of the most important improvements and new features you would benefit from if you migrate from Axon 3 to Axon 4:


1 - Unified Distributed Messaging Solution

Arguably one of the main reasons AxonIQ started in the first place. Sending commands, events and queries in a single application is straightforward with the provided message buses. Expanding this to communicate all messages between different instances required some expertise back with Axon 3. High availability or a desired microservices architecture however demanded this from Axon.


With Axon 4, distributing command, event and query messages has never been as easy. The seamless integration Axon Server provides with an Axon application makes sure of this. The predefined defaults of framework and server allow for enhanced focus on what matters to your application: the business functionality. Just so that you do not have to think about how to store events or how to distribute your commands.


With the unified messaging solution a developer can go back to implementing that new feature the business wanted or that bug withholding sales, instead of figuring out how to connect your applications with one another. Of course, you still have the freedom to choose a multitude of other open source solutions to this end, but none of these can be regarded as an out-of-the-box solution like Axon Server.

2 - Tracking Event Processor Enhancements

Updating your views, management information and search capabilities based on the latest events flowing through your system becomes a fact of life when using Axon. Ensuring this happens efficiently enough, especially with the potential for large bursts of events, is of utmost importance to stay ahead of the competition. To gain the upper hand, this process should be separated from the rest of your application, added with the option to scale out. Needless to say Axon keeps improving on this topic to minimize “read-model latency”.


It is the Tracking Event Processor in Axon, the technical component used to retrieve and handle events, which provides such flexibility. It can handle events independently from other parts of your system. Added, it allows for scaling out this capability by introducing more threads in to the process of reading and handling messages. Axon 3 already contained the tracking event processor, but in Axon 4 it is the (sensible) default. This ensures that you will benefit from this perks immediately.

There was one major pain point with tracking processors in Axon 3 though. Several users noted they had peak performance requirements of their tracking processors. They could not always anticipate when these critical moments occurred though. Hence we had the request whether it was possible to dynamically scale a tracking processor.

In Axon 3 this was however not an option. Instead it required an operator to shutdown the application entirely, remove the processors old token (note: the token is used to maintain the processors progress), change the configuration for scaling purposes and only then could they start the application again. Obviously a rather intricate process, far from allowing dynamic scaling.

Hence in Axon 4 we introduced a solution to this, which we have called the “split and merge” functionality. Through the feature you can split the process into several processes or merge them back together. This thus makes dynamic scaling a piece of cake!

There was still room for improvement when it came to tracking processors though. Operators of Axon applications needed information and tooling to correctly control these processors. A dashboard allowed for monitoring the state of the processor, so that for example an operator could deduce whether he/she should scale up (or down). The tooling in turn was required to actually control the processor in a running system. Many of our developers heard these requirements and several client specific versions have been built.

Due to this recurring requirement AxonIQ has started to provide tracking processor monitoring and tooling out of the box. Axon Server will create a dedicated page per tracking processor present in your application, showing all the known metrics and the required handles to take control over the processor. This provides a one stop shop for operators to check whether splitting or merging is actually needed. It will even open up the possibility for Axon Server to automatically scale up and down, which we will surely add in a future release.

3 - Real-time Event Streaming

Although the Tracking Event Processor is pretty neat, there was still one performance impact which could be tackled. In Axon 3, you were confined to using a relational database as the event store. The implementation made it so that a tracking processor had to poll the store on its own accord. This leads to a situation where tracking processors which reached the end of the event store are constantly checking the database for new events. A back-off period is in place of course. But still, this was and is a performance impact noted by a multitude of users.

We felt this could and should be improved on, thus we did so with Axon 4. We do this through real-time event streaming, made possible by Axon Server. In an Axon plus Axon Server environment, your tracking processor will register itself. In turn Axon Server will push any event it receives to the processors immediately, in real-time. This approach greatly enhances performance of event handling opposed to the polling approach used with relational databases.

4 - Aggregate Modeling Improvements

We all know that Axon provides a great stepping stone to DDD. Hence, domain modeling will be applied throughout the business by analysts and developers alike. It is in these modeling sessions that a hierarchy might occur. Let me give an example of this which we noticed at a bank.

This specific banking environment had modeled the notions of contracts in their application. A contract could however be of several types. Some actions could be taken generically, thus on any type of contract, but some were specific for a given contract type. When doing DDD this scenario is perfectly feasible. However, Axon did not support the same modeling experience in code, up till now.

In the latest release of Axon (4.3), we have introduced the notion of “Polymorphic Aggregates”, opening up the possibility to derive a model hierarchy. This will allow the previously mentioned banking environment to take their hands-on contract modeling session and map it directly into the application. This addition greatly strengthens the modeling experience, making the application resemble the domain more closely.

Another request we received several times was how to define an operation which would either create the model or update the model. This functionality is achievable with Axon 3, but essentially requires you to always try to create and thoughtfully catch the possibility of an exception that it was already created. If so, that’s when you would update the model. Doable of course, but “ugly” to write and a misnomer for the development experience with Axon.

You might expect this, but with Axon 4 you can thus define an operation to either “create or update” a given model. The developer will configure this on the model (read: aggregate implementation), omitting the need for him/her to draft up this functionality themselves.

5 - Multi-Context Support

When doing DDD, the notion of Bounded Contexts will definitely cross your path. Axon has been talking about the concept since prior to Axon 3, but true support for this was always in the hands of the developer themselves. Let’s give an example to clarify why defining and bounding different contexts is desirable in your application landscape.

We go back to the bank client mentioned in the previous section. They are using Axon in several departments of their company. For example the mortgage, credit card and loan departments. Every department is in charge of their own piece of software, but these pieces will require communication with one another at one stage. For reporting maybe, or to validate a user’s credibility when applying for a mortgage.

The notion of a “user” will thus coincide between these departments. However, a “user” has a different set of requirements in the mortgage space than it has when applying for a credit card. To ensure consistency within the department, the mortgage application should not be polluted by the credit card’s idea of a user and vice versa. Instead, the required communication between the two should be confined to a consolidated global description instead.

It is the above scenario which describes the desire to derive distinct compartments which have their own context. Added, they should be shielded from outside notions of the world, bounding themselves from the rest. As I stated earlier, we at AxonIQ have been preaching this necessity, but did not provide an out of the box solution. A solution which bounds the communication between applications tied to the same piece of infrastructure for messaging and storage.

With Axon 4 however, we are allowing the option to define and support multiple contexts. This will ensure the communication of your applications will receive dedicated channels per context, as well as a dedicated storage location for the events. It greatly simplifies the work developers and operators would otherwise have put into setting up all these dedicated messaging channels and databases.

6 - Increased Development and Support Effort

As you might have noticed from the previous topics, is that every one of them was one way or another driven by user feedback. From trading platforms to car companies, and from banks to regular developers interested in doing DDD, CQRS and Event Sourcing. Each and every one of them, you very likely included, gave us the certainty and trust to keep working on Axon.

The increasing influx of existing and new users, with reoccurring or novel feedback, provided the assurance that AxonIQ could and should be a thing. But, how does this benefit your migration from Axon 3 to 4? Well, Axon 4 is the first major release the AxonIQ team undertook. Back in October 2018 when it was released the team was about double the size compared to the Axon 3 team. Nowadays we have a team-size already quadrupling that at the start of 2020.

Needless to say, Axon 4 had and will have far more development power and support knowledge backing it then Axon 3 ever will. Expecting bugs to be resolved quicker, features to be included faster and questions to be answered more swiftly belongs to the ecosystem of those using the latest version. Do know that this does not hold for Axon 3 any longer. We are no longer planning to do any bug or feature release on Axon 3, only leaving the possibility to have questions answered through some of the public fora.


Concluding, we firmly believe that everything we are adding into Axon right now, the top five pointers among them, greatly increases any users experience. Development cycles, application performance and flexibility should all way higher than the overall cost required to perform the migration. If the above has convinced you to follow up with a migration from 3 to 4, know that we are more than happy to provide helping hands. Thus, please do not hesitate to contact us at AxonIQ!

For more technical information check the reference guide.

Go ahead and download Axon at

Subscribe to blog notifications