TrackingProcessor scalability

Hi,

I’m digging into Axon 3 from few days to see if it fits our needs and I have a question about scalability of tracking processor in a microservices architecture.
I made few tests and I saw if I configure my tracking processor to be mono thread, and I set the initial segment number to 4, if I have only 2 instances of my microservices which handle the events, only half of the events will be processed, which make sense because only 2 segments from 4 are used.
If I have 4 segments but only 2 instances of my microservices, I guess half of my microservices will never process any events because only 2 of them can borrow a segment.

How can I achieve a microservices architecure using Axon 3 with ES where I can at runtime tweak the number of instances to fit the workload.
I think this is directly related to this : https://github.com/AxonFramework/AxonFramework/issues/634
But, is there currently any workaround to solve this ?

Thank you.

Hi Versi,

The ticket you’re referring to is exactly what I would’ve shared giving your request.
We do see the need to be able to automatically merge and split segments up as the number of nodes changes in your system. Not just from a framework-only perspective, but this is also needed for AxonHub/AxonDb to be able to automatically scale up/down.

I can only think of certain compromises you can make with more threads per node, due to which some threads will be idle. This isn’t ideal of course, hence why the issue is in place. What you could also do as a compromise is to actively shutdown your TrackingEventProcessors when you’re adding/removing nodes from the system. Once they’re shutdown, you could initiate a merging/splitting process of the tokens, after which you can start them up again with the ideal balancing.

Other than that I cannot think of a workaround at this point in time. Sorry to (very likely) disappoint you now Versi.

I’d suggest to stay tuned on that specific issue and to use it as soon as it’s in.

That’s my 2 cents.

Cheers,
Steven