Forgive me nativity as I’m new to the event sourcing and CQRS world. I’m hoping axon and this forum can solve some of the questions i have around managing a distributed transaction.
I’m still making my way through all the documentation and samples axon has to offer. Please forgive me if this question has already been answered.
I’m still trying to nail down all these concepts in my head… but ideally, the question i’d like to answer is some way or form is…
How do we achieve command handling and event handling at scale?
For the eventBus, I’ve seen mention on the group about possibly using Kafka consumers to fulfil that role.
For the commandBus, I’ve seen reference to JGroup connectors to solve distributed command handling. I’ve also seen a few concerns raised about this, with regards to using it in the cloud.
So my question is…
Has anybody looked at using spring cloud and particularly ribbon to solve distributed command handling?
Instead of statically binding to VM’s , why not plug the command handling into the service discovery and let ribbon(or something similar) do the client side load balancing?
Or is there something else i’m missing that JGroups gives us?
first of all, yes, we are looking at Spring Cloud as well for message routing in Axon, and vice versa as well. We have regular discussions with the Spring Cloud developers about this. The conclusion somfar is that it is probably suitable for events, but most likely not for commands.
Events and Commands are very different types of messages. Events describe something from the past. They’re sent using fire and forget, and multiple components may be interested in processing them. Therefore, Events are sent through some sort of message broker. In Axon 3, the event store itself can act as such a broker.
Commands on the other hand are sent to exactly one component (although the sender doesn’t care which component this is). There may be multiple candidates, but then there must be a ore-defined way to decide which one get it. Typically, these would be multiple instances of the same component on different machines, but they may also be different components in an AB testing situation.
Routing commands is easy, conceptually. The aggregate instance that they target is their routing key. Two commands targeting the same aggregate must be routed to the same machine.
For events, this depends on the requirement of each processing component. Therefore, event processors typically read all events, and discard the ones they shouldn’t process, for example based on a hash function on a set of properties on these events.
Since command routing is done based on information inside the command itself, it is very suitable for consistent hashing. For this, each node needs to know about which other nodes are present and then select a destination based on the hash function. Jgroups provides both the discovery and the communication between nodes, making it a suitable library for command dispatching. However, any discovery can be combined with any communicatino protocol if you wish. However, it this moment, we do not know of any discovery implementation that allows you to retrieve a candidate instance based on an input parameter, which acts as the input of a consistent hashing algorithm…
Hope this clarifies things a bit. It’s a long and complex story over email…