Axoniq Framework 5.3.0 Release

We’re excited to announce the latest release of Axoniq Framework 5.3.0 which adds multitenancy and distributed tracing, along with more changes that give you more say over how to handle your event streams: when a processor records its progress, and what shape an event keeps once it's stored. 

What’s new in the release:

• One deployment, many tenants. Multitenancy keeps event streams, command routing, and query handling isolated per tenant, so you get isolation you can point a customer at without running a separate deployment for each one.

• Visibility into what actually happened. Distributed tracing follows a request across every service and handler it touches, so incident response stops being log archaeology. Subscription queries now report how many subscribers received each emit, so you can tell the difference between delivered and dropped.

• More control over your event model. Handlers doing asynchronous work decide when their progress marker advances. Event transformation can now split one stored event into several, going forward.

Multitenancy* and distributed tracing* both attach through the configuration API's decoration support, applied to infrastructure components at configuration time. In Axon Framework 4 this functionality lived inside the infrastructure. This made management and extension  extremely difficult given the scope of some infrastructure components. However, on the outside, there’s only improvements and simplifications for both. Update to Axoniq Framework 5.3.0 today and read the release notes for the full list of what's new in this release.

Multitenancy

Axoniq Framework 5.3.0 introduces multitenancy support.* A single deployment now serves multiple tenants, with event streams, command routing, and query handling kept isolated from each other.

• No more choosing between a separate instance per tenant or sharing one and accepting the blast radius

• Built for platform and ops teams running at scale

Platform and ops teams running at scale get the isolation guarantees with a separate deployment per tenant, built into one fleet of tenant-aware infrastructure instead.

This iteration of multitenancy* has seen some structural adjustments. The framework attaches tenant awareness through the configuration API's decoration support. Every “tenant context” is applied to infrastructure components at configuration time, which keeps the number of duplicated components low. Importantly, Event Processor instances are shared across tenants instead of having one per tenant. Doing so, the thread pool count stays flat as tenants are added, and onboarding a tenant becomes a configuration change your capacity planning barely notices. Lastly, every user is able to derive “tenant-scoped components” and wire them in their handlers. This allows you to draft custom tenant-specific caches, repositories, and services alike.

Distributed Tracing

Axoniq Framework 5.3.0 introduces distributed tracing.* Requests are traced as messages flow.

• Trace a request end to end across services and handlers, no manual log correlation

• Incident response goes from reconstruction to lookup

Every request is now traced as it moves through commands, events, and queries — which service and handler touched it, and where. A request that spans five services and a dozen handlers is traceable end to end the moment something looks off, turning incident response into a quick lookup.

Tracing attaches through the same decoration mechanism as multitenancy, following Axon Framework 5's internals directly. This ensures spans map cleanly onto the work the framework is doing, regardless of whether it is imperative or reactive. If you traced an Axon Framework 4 application, the API here follows Axon Framework 5 conventions and the efficiency gains of Axon Framework 5 internals come with it.

*Available for enterprise customers only.

Self-Checkpointing Event Handlers

Axoniq Framework 5.3.0 opens up control over when a streaming handler's progress marker advances, instead of assuming it advances the moment a batch commits. A handler doing asynchronous or eventually-durable work — an async write to a search index, an in-memory model saved later — can now report progress only once its write is actually durable.

The framework's recorded progress always matches what's actually saved, so a crash never leaves you debugging a gap between what the framework thinks happened and what your data shows. The open extension is free and changes nothing by default. Axoniq Framework builds a ready-made engine on top for teams who'd rather not build their own reconciliation and rollback logic from scratch — it auto-detects which handlers need this per processor, and reconciles multiple handlers sharing a segment down to one agreed position.

Note that self-checkpointing is marked “internal” throughout, with the `@Internal` annotation. We use this annotation to mark interfaces, classes, methods, and constants as being internal to the Framework and that as such the user may expect changes in the future. Self-checkpointing is marked internal to clarify the API is experimental still.

Event Transformation

Axoniq Framework 5.3.0 completes the event-transformation chain with the one remaining case: turning a single stored event into several, going forward.

Say you shipped an event that bundled two facts that later became distinct concerns — "course published" conflated with "initial capacity set." Because your event store is append-only and shared by many independent, often-replaying consumers, physically rewriting historic events is invasive, and most teams rule it out on principle. Describe the split once, and every consumer going forward — projections, event-sourced aggregates, replaying processors — sees the two logical events instead of the old bundled one. Every produced event keeps the original's identifier, timestamp, and stream position; nothing gets renumbered.

Also in the Axoniq Framework 5.3.0 Release

• Map support for entity members. Add, look up, and remove entity member entries by key. A Map-shaped user coming from Axon Framework 4 stays a Map instead of being rewritten into a list with a manual lookup loop. What looked like a structural rewrite is close to a straight swap on the same field. 

• Subscription query delivery counts: every emit/complete method now reports how many active subscribers received it, so you can detect and retry on a zero or unexpectedly low count instead of emitting into the void with no delivery visibility. 

• Consistent behavior when an entity doesn't exist yet: using a stateful handler, you can now clarify if the entity is expected to exist, yes or no. Simply mark the @InjectEntity annotated parameter with @Nullable to clarify you are okay with receiving null. Don’t want to handle a null entity? Simply not use @Nullable, and Axon Framework will throw an EntityNotFoundException if it doesn’t exist yet.

Stay Current

Update to Axoniq Framework 5.3.0 today and read the release notes for the complete list of fixes and enhancements. Questions or feedback? Drop them on the Discuss forum or open a GitHub issue.