Rethinking Events in Axon Ivy
This is a technical deep dive into how we handle events in Axon Ivy.
Today, we use an internal framework based on our persistence layer to react to changes in the system database. It is triggered whenever a configured table changes.
For create and delete events, this works well. Change events, however, are more difficult.
A database change only tells us that something was updated. It does not necessarily tell us what actually happened.
For example:
A project has been deployed.
From a business perspective, this is a meaningful event. From the database perspective, it might simply be an update to one or more records.
This distinction is important.
Database-driven events are useful for technical concerns such as:
- cache invalidation
- auditing
- logging
But they are not a good fit for use-case-driven events such as "a project has been deployed".
Our goal is therefore to separate these two concepts:
Persistence events describe what changed.
Application events describe what happened.
Most of our current listeners use the persistence-based framework for cache invalidation, but there are also listeners that need more semantic, application-level events.
The redesign should make this distinction explicit.
There is one additional challenge: clustering.
When an event occurs on one Axon Ivy node, it may need to be received by listeners on other nodes as well. This is especially important for cache invalidation, where each cluster node may maintain its own local cache.
So the new event model needs to support both application-level semantics and cluster-wide event distribution.
The key idea is simple:
Database events tell us what changed. Application events tell us what happened.
Keeping these concepts separate gives us a cleaner and more maintainable architecture.
