How can I make sure the read store is in sync with the event store and events are successfully written to the read side? Do we lose any events in case of failure of application or any other components? Do we see the same events after recovering from the failure, and if yes, does AxonIQ provides any support for idempotency?
You can’t really be sure you’re in sync, since it’s eventually consistent. Although when the streaming event processor doesn’t proces new events anymore, you are likely in sync.
To handle failures a streaming event processor is using a token store. This stores tracking tokens, so it can recover after failure or restart and continue reading events where it was left.
Please let us know if you have additional questions, or take a look at the reference guide.
1 Like
As @Gerard said you cannot make sure the read side is in sync with the event store with the default configuration.
However I think you can do it if you change the configuration:
- use the same DB for the event store and the query store (e.g. postgres)
- use all Subscribing Event Processors when you want immediate consistency
- make sure a propagating event error handler is set up so any exceptions will cause a rollback
EDIT: I should add - this is definitely not recommended by default (and you should have a very good reason to do this).
2 Likes
Thank you for the reply.
I also wanted to know that is it possible to see the same event again after a failure? If yes, then how to achieve idempotence in our application?
Yes, assuming you use a streaming event processor, it will keep track of the events successfully handled using a token store. In most cases updates to the token store will be in the same transaction as updates to the representation, making sure they are in sync.
I’m saying most cases here, as for example when using Mongo to store the representation and the token, no transaction will be used.
1 Like
Thank you. I understand
1 Like