Grouping event handlers in consumer groups

Hi, is there a way to group event handlers in a style Kafka uses for consumer groups?
I understand that all event handlers get the same event objects. Is there a way to group some event handlers so that only one event handler in the group gets the event object?
That way I could refresh a search engine or a RDBMS, each represented by a group of event handlers (running in replicated search engine micro services or database micro services).

Right now all event handlers would create or update, so for example adding a product to a cart would lead to an added product per micro service.

Best regards,
Erik

Hi Erik,

When it comes to segregating Event Handling over different Query Models (which you exemplify with “search engine” and “RDBMS”), you should consider creating dedicated Event Handling Components.
To further ensure that such an Event Handling Component becomes “its own consumer group” so to say, you will need to make sure to use dedicated Event Processors for each of these Event Handling Components.

The Event Processor in Axon is the technical means to retrieve an event stream and provide each event to the Event Handling functions you write.
Additionally, such an Event Processor can be in charge of any number of Event Handling Components.
The ensure segregation, you’d thus have to assign a dedicated Event Processor to an Event Handling Component.

Axon Framework to this ends provides you the means to specify a Processing Group for a given Event Handling Component.
This can either be configured through the EventProcessingConfigurer or by annotating your Event Handling Component with the @ProcessingGroup annotation.
For more specifics on Event Processors, I’d suggest to read the Reference Guide on this topic.

Per recommendation I would definitely assign a dedicated Event Processor per form of Query Model you’d introduce.
That would thus justify a distinct Event Processor which is in control of given the events to the Event Handling Components which update your “search engine”.
Similarly, you’d have a dedicated Event Processor, with distinct Event Handling Components which are in charge of updating a specific read model in a RDMBS instance.

Segregating these concerns as such gives you the possibility to “replay” the events for a specific query model.
Mind you that to replay a given Query Model, that model’s Event Handling Components are inclined to be backed by a TrackingEventProcessor.

Although you use the term “refresh” in your question, I think you’re looking for “replay” or “reset”; hence why I am pointing out the previous.

Hope this sheds some light on the situation Erik.

Cheers,
Steven