Should microservices connected with axon share the axon framework related tables?

Viewed 572

I am starting a project where I want to have multiple services that communicate with each other using the axon server.

I have more than one service with the following stack:

  • Spring Boot 2.3.0.RELEASE (with starters: Data, JPA, web, mysql)
  • Axon Spring Boot Starter - 4.2.1

Each one of the services uses different schemas in the mysql server.

When I start the spring boot service with the axon framework activated, some tables for tokens, sagas, etc are created in the database schema of each application.

I have two questions

  1. In the architecture that I am trying to build, should I have only one database for all the ‘axon enabled’ services, so the sagas, tokens, events, etc are only in one place?

  2. If so, can anyone provide an example of how to configure a custom EntityManagerProvider to have the database of the service separated from the database of Axon?

2 Answers

I assume each of your microservices models a sub-domain. Since the events do model a (sub)domain, along with aggregates, entities and value objects, I very much favor keeping the Axon-related schemas separated, most likely along with the databases/schemas corresponding to each service. I would, thus, prefer a modeling-first approach when considering such technical options.

It is what we're currently doing in our microservices ecosystem.

There is at least one more technical reason to go with the same schema (one per sub-domain, that is), both for Axon assets and application-specific assets. It was pointed out to me by my colleague Marian. If you (will) use Event Sourcing (thus reconstructing the state of an aggregate by fetching and applying all past events resulted after handling the commands) then you will, most likely, need transactions which encompass this fetching as well as the command handling code which might, in turn, trigger (through events) writes to your microservice-specific database.

Axon can require five tables, depending on your usages of Axon of course. These are:

  1. The Event table.
  2. The Snapshot Event table.
  3. The Token table.
  4. The Saga table.
  5. The Association Value Entry table.

When using Axon Server, tables 1 and 2 will not be created since Axon Server is the storage solution for events and snapshots. When not using Axon Server, I would indeed suggest to have a dedicated datasource for these.

Table 3 which services the TokenStore, should be as close as possible to your Query Models. The tokens portray how far a given EventProcessor is with handling events. As these EventProcessors typically service projectors which create your query models, keeping them together is sensible from a transactional perspective.

Table 4 and 5 are both required for Sagas. The "Saga table" stores the serialized sagas, whereas the "Association Value Entry table" carries the associations values between events and sagas so that the framework can load the right sagas. I'd store these either in a dedicated database or along with the other tables of the given (micro)service.

Related