Multiple Event Stores

[Bram]

Hello,

We’re currently planning to switch Axon Server Developer Edition (already used in production) to Axon Server Professional Edition as the latter one provides useful features like multi-context, high scalability etc.
All events are currently stored in a SQL database and we want to keep it like that. Basically, we’ll map one context to one identified Bounded Context.

Now, the question is if it’s possible to provide a separate SQL schema for each Axon context?
This way, all events of context1 are persisted separately from context2.

Other question: is it possible to capture events from context2 in an application that is ‘connected’ to context1?

Is there anything else we’ve to consider? For instance, can saga’s listen to events coming from multiple contexts…?

[Steven_van_Beelen]

Super nice to hear you’re looking into moving to Axon Server Pro, Bram!
What surprises me a little, though, is that you state you want the events to stick to a SQL database.

Just for clarity, but you are intentionally not using the Event Store functionality of Axon Server in that case, right? Knowing this bit of info is crucial for what to suggest concerning your context, by the way. Hence why I am asking

[Bram]

Hi Steven,

We started years ago with a SQL event-store for several reasons.
We’re now discussing with the AxonIQ team if there’s some way to circumvent our specific requirements in such way we can migrate to Axon Server Professional for all our Bounded Contexts.

[Steven_van_Beelen]

Aah gotcha Bram, thanks for sharing that detail with us

@Bram

Now, the question is if it’s possible to provide a separate SQL schema for each Axon context?

You can, but all of that would be custom work in AF4. By default, Axon Framework expects a single EventStore. And, essentially, you want several event stores, each with their own storage layer.

@Bram

Other question: is it possible to capture events from context2 in an application that is ‘connected’ to context1?

Yes, you can. You’d just need to define a MultiStreamableMessageSource that ingests from several StreamableMessageSources. The EventStore interface of Axon Framework is a StreamableMessageSource, btw.

@Bram

For instance, can saga’s listen to events coming from multiple contexts…?

Yes, they can! Per the previous comment. A Saga is nothing more then a specialized Event Handling Component with a EventProcessor in front of it. If that EventProcessor uses the MultiStreamableMessageSource, you’re good.

@Bram

Is there anything else we’ve to consider?

Yes, and a rather big one perhaps. The multi-context support of Axon Server really revolves around the Event Store section. When defining several contexts in Axon Server, you essentially have the base infrastructure components per context.

Assuming you have context X and context Y, you can state you have a CommandBus for both, a QueryBus for both, and an EventStore for both.
Actively deciding not to use the storage side means a lot of custom configuration. Not that it’s not doable, from a pure technical perspective, it seems like “wasted” effort to go that route.

Now, I can not foresee why migrating to Axon Server as the storage solution is a big no-go. But I do want it to be clear (for you and other readers) that that decision will have impact on the configuration side of things.

---

Regardless, I hope the above helps you further, @Bram!