Downsides to using one EventTrackingProcessor for multiple different Sagas.

Imported from Google Groups
#1

Hello all.
For context I’m using Axon v 4.1.2 with SpringBoot but without the AxonServer. I am building an ACL and it currently has 4 Sagas. Each Saga will consume specific events from the same KafkaMessageSource. By default Axon will configure an unique TrackingEventProcessor for each saga. My question is this: Is there any reason why I should not use one processing group [TrackingEventProcessor] for all the Sagas ? I have read https://docs.axoniq.io/reference-guide/configuring-infrastructure-components/event-processing/event-processors multiple times, and even read the TrackingEventProcessor java source code and I could not find any downsides myself. As far as concurrency, it appears that I should just ensure that I have 4*N segments, and configure axon.eventhandling.processors.name.threadCount to be at least 4 where N is the number of live instances of the application. I realized that , this does not mean that the Event-Processor will assign one thread to each Saga.

P.S.
We have more than one saga because they are aligned with distinct business processes. I believe we could put all the code into one large Saga class but that would not make sense from a code management point of view or business point of view.

#2

Hello Brian.

Event processors are indeed a way to distribute the work load to multiple threads. Each processor tracks what was the last event processed for it. Each processor by default uses threading model where for specific aggregate it process messages on specific thread, you can change it as you said.

Now when it comes to saga i rarely use common processor bus as you might realize is that if N sagas are handling one bigger business process it might be helpful to assign them to one processor so if you want to replay this process from scratch you can delete the processor’s tracker from your database and all of the sagas will be replayed, otherwise you would need to delete N trackers. The ordering of events in saga should be a concern within a saga itself.

With that being said i have never configured any processor for Sagas, all of them use unique name based on the class name. The only time where i explicitly define processor is for the projections, i use one processor for N projections so when i want i can as i said, replay the whole projection with ease.

Cheers.

#3

Hi Brian, Robert,

Whether it makes sense to group these sagas in a single Event Processor on not, depends on the non functional requirements you have in your project.

Are those sagas going to handle hundred thousands of events per second?

Then I think it would make sense so segregate them from one another in different Event Processors.

Will your application run on hardware with constrained processing/memory?
Then I think it would not make sense to have several Event Processors (read: threads) to maximize usage.

The replaying point brought up by Robert is in most scenarios relevant to think about.
However, as sagas typically perform operations, then chances are very high that you do not want those operations to occur again.
As such, replaying should not impose constraints on whether you group your Saga Implementations under a single Event Processor, yes or no.

Concluding, as you have deduced Brian, from Axon’s perspective it does not really matter which way you go.
It more so depends on what you, in the end, expect from your application.

That’s my two cents on the situation.

Cheers,
Steven