Events Sourcing and Axon Server

Data centre
Reading Time: 3 minutes

Axon Server

It’s a component that allows for different/multiple instances that are implemented in the axon framework. Axon server has the capability to communicate that your application is running in scaling mode. There is no matter application running in the micro-services environment, it’s transparently working.

Run Axon Server

We can use the official docker image to startup an Axon server instance:

docker run -d --name axonserver -p 8024:8024 -p 8124:8124 axoniq/axonserver

Another option we can startup a server instance by downloading the binaries from here.

In order to check the installation was succeeded, browse to “http://localhost:8024/” and we should see the Axon dashboard.

Messaging types

Axon distinguishes messages into three categories: Commands, Events & Query. 

Commands- Route is single handle and use consistent hashing to generate the result 

Events – It’s follow pub/sub patterns to distribute to logical handlers

Query –  It can be used route with load balancer, a single or multiple node to gives the answer

Events Sourcing

Event sourcing is a very specific subset of Event-Driven Architecture. Events are used to just not notify different components its something happens and events become the heart of your data storage. 

In the architecture of an event-sourced application, the event store is the database system used to store the events.

Most of the systems typically store information as State. The history can be essentially captured from the state. You have the latest state of information in the database. Let this example have an Order. 

Business Reason

  • Auditing/ Compliance/Transparency 
  • Data mining, Analytics

Technical reasons

  • Guaranteed completeness of raised events
  • Single source of truth
  • Concurrency/conflict resolution
  • Facilitates debugging
  • Replay into new read models (CQRS)
  • Easily capture intent

High Available

Axon Server can be work in clustered mode and each node in the axon cluster is active and applications are dynamically balanced the nodes. Axon based Instances of the same application will be connect to the same messaging node to optimize performance.

QoS Messages

Axon based application can indicate priority of their request. For example, commands originating from a batch process can be executed with lower priority than online requests.

Access control

Axon based applications are need to be granted access to the messaging platform. This avoids the risk that random application can start sending commands into the system.

Implementation technology

Axon Server has been developed in JVM and building on Spring Boot. It is comes as a distributed single jar file containing all libraries. The Axon Server configurations are stored in h2 database and that contains the information about the messaging platform nodes and the applications that have access.


Axon framework makes easy to implement a CQRS pattern and architecture with Zero-configuration message router and event store, ready to run locally some other resources that you may find interesting.

Written by 

Abid Khan is a Lead Consultant at Knoldus Inc., postgraduate (MCA), and having 5+ years of experience in JavaSE, JavaEE, ORM framework, Spring, Spring-boot, RESTful Web Services, Kafka, MQTT, Rabbitmq, Docker, Redis, MySQL, Maven, GIT, etc. He is a well-developed professional with a prolific track record of designing, testing, and monitoring software as well as upgrading the existing programs.