AxonIQ Axon Framework
Code, Deploy Value

Microservices Architecture with CQRS, Event Sourcing and Axon Framework

14 April 2025 - 5 minutes reading

Thinking about the development of an architecture based on microservices is not trivial. If, in addition, the system needs to efficiently manage electricity, as in the case of energy communities, the complexity increases even further.

In recent years, event-driven architectures have become increasingly popular to tackle scenarios where scalability, resilience, and traceability of state changes are critical. Among the most commonly used patterns in this context are CQRS (Command Query Responsibility Segregation) and Event Sourcing (ES). But why choose this combination?

A Bit of History: Why CQRS + Event Sourcing?

CQRS originates from the idea of separating read (queries) and write (commands) models to optimize performance and reduce complexity in transactional systems. Event Sourcing, on the other hand, is adopted to maintain a complete history of state changes through immutable events, facilitating auditing, rollback, and system state recovery.

The combination of CQRS and Event Sourcing allows the creation of highly scalable systems with clearer management of concurrency and data persistence.

CQRS: Separating Commands and Queries

In the traditional model, reads and writes often share the same data model, leading to inefficiencies and scalability issues. CQRS proposes to separate these two aspects:

  • Commands: Represent actions that modify the state of the system, such as MakePayment or ConfirmOrder.
  • Queries: Retrieve data from the current state of the system without modifying it.

This separation allows for independent optimization of reads and writes, improving performance and reducing concurrency conflicts.

Event Sourcing: Storing State through Events

Unlike traditional databases, which overwrite updated data, the Event Sourcing pattern stores every state change as immutable events.

An event is generated in response to a valid command and is saved in an Event Store, which acts as the system’s “source of truth.” To retrieve the current state of an entity (e.g., an order), simply replay all the events associated with it.

Here’s an example:

  1. A PlaceOrder command is sent to an aggregate.
  2. If the command is valid, an OrderPlaced event is generated and saved in the Event Store.
  3. The aggregate’s state is updated based on the applied events.
  4. Other parts of the system can react to the event asynchronously.

Benefits of CQRS + Event Sourcing

  • Scalability: separating read and write operations allows for independent optimization and scaling.
  • Complete history: every change is tracked, enabling advanced auditing and debugging.
  • Resilience: the state can be reconstructed at any time by simply replaying the events.
  • Ease of integration with reactive and event-driven systems.

Application Example: A Case Study in the Energy Sector

The case study we will cover in the following paragraphs involves Intré’s collaboration with a client on the PlatOne project. Intré utilized AxonIQ solutions, specifically the Axon Framework, to develop a simulator in the Energy sector.

The Context: PlatOne Project

The European PlatOne project (PLATform for Operation of distribution Networks), funded by the European Union under Horizon 2020, aims to develop and test advanced technological solutions to enable energy flexibility in an open and inclusive market. The consortium addresses the challenge of managing increasing network congestion caused by the spread of renewable energy sources with variable generation and the electrification of heating, cooling, and mobility.

The Software Product Developed

Intré supported the client in the design and development of a strategic microservice for managing calculation sessions in the energy sector. The goal was to create an application capable of simulating future scenarios on the existing electrical grid — from primary and secondary substations to household meters — in order to identify potential critical issues.
Based on the given calculation data, the software detects possible electrical problems, such as voltage or current overloads.

Identifying critical issues allows for more efficient management of a city’s electrical grid, also enabling the “reuse” of existing electricity to direct it where needed, instead of purchasing it from the GME (Energy Market Operators).

Coordinating Complex Simulations with a CQRS + Event Sourcing Architecture

One of the key elements of a system based on CQRS + ES is the ability to coordinate complex processes in a reliable and scalable way. The fully asynchronous system has made the adoption of CQRS natural for managing workflows and monitoring the progress of simulations. Commands are used to start, control, and complete calculation sessions, while events track every state change.

Event Sourcing has enabled the recording of every stage of the simulation, allowing the reconstruction of the data sequence in case of errors or the need for audits. Additionally, defining specific commands and events for each type of calculation has made it easier to extend the system with new functionalities.

The Adoption of Axon Framework

One of the critical aspects in implementing CQRS + ES is managing the complexity related to event sequencing and command propagation. To simplify this process, Axon Framework was adopted, an open-source solution for Java and Spring Boot.

Axon Framework provides a complete infrastructure for managing aggregates, commands, events, and queries within a CQRS + ES-based architecture. The framework also includes a Command Bus called the Disruptor Command Bus, which offers asynchronous execution and high performance, reducing overall computation times.

The company AxonIQ, which develops the framework, has also released complementary products like Axon Server and AxonIQ Console, which further simplify the management of event-driven systems.

In the specific case of the client, Axon Framework was used with a preference for saving events to a database and leveraging the advanced capabilities of the Disruptor Command Bus to parallelize command dispatch to the aggregate. This ensured high performance and reduced execution times, essential for optimizing the energy calculation processes managed by the platform.

Conclusions

For the development team, adopting “Axon Framework” was a natural choice. The integration with Spring Boot automated most of the required objects, allowing developers to focus on defining the data model (Aggregate), commands, and events.

Thanks to CQRS + Event Sourcing and tools like “Axon Framework”, it was possible to develop a scalable, reliable, and easily extendable system, while also optimizing performance and managing calculation sessions on the DSOTP platform.

Article written by