My application has a similar setup as this popular example of spring microservices and cqrs with axon : https://github.com/benwilcock/cqrs-microservice-sampler
So far my cqrs setup works as expected:
- comes a request from the GUI-> goes to the command microservice which stores the event in a mongodb event store, propagates it to the query microservice through RabbitMQ and the query microservice will maintain its own Relational Database, which is then used
for queries on the domain.
My problem now is what happens when I want to replay the events. The whole point of keeping an event store, is to be able to replay all events and reconstruct whole databases from scratch in other applications-microservices whatever.
RabbitMQ doesnt hold the events, if someone picks them, So some kind of replaying through RabbitMQ is as explained and in this group earlier, not possible(although some kind of persistence configuration is possible probably, I wouldn’t want to do it with rabbitmq).
From searching the group and the documentation I understand that I need to use tracking processors and the whole thing with a token store. Then, I can setup logic for replaying events, or even delete manually the token and force a replay(nice option too).
But , I understand that this is not possible with my existing architecture with RabbitMQ.
So to sum up, I see 2 roads here:
Either use RabbitMQ and probably lose the replay of events. Searching the group, I couldn’t find a way to replay the events using RabbitMQ. The events are in the event store managed by the command side, so would it be possible somehow that the command side replays all or specific events to specific queues(so query services pick them up and some kind of reconstruction happens).
As I understand , in this scenario with the AMQP broker, the query side uses subscribing processors, and is passive in simply receiving events, and never actually touch the event store directly.
Either remove RabbitMQ(for axon specific work), and have the query side use tracking processors and access directly the event store, and do any replays by itself and also maintain a token store.
In this scenario, command and query services communicate through the event store, meaning that the event store is updated by the command side, and query side reads from there.
My questions are:
Do I miss something regarding rabbitmq and replay of events?Is it possible somehow?
Which of the 2 roads would you suggest?
While I would like the query side to be more passive and do not access directly the event store, from briefly searching about the topic, I see that the tracking processors with the tokens et all, are a safe reliable way to replay events.