I want to embrace the eventual consistency, but I worry that it may not be possible (without introducing too much complexity ).
Using Axon as CQRS framework, the inconsistency may occur : (1). between Query and Command , or (2) occur in Command side only when multiple commands need to collaborate with each other and one of the command get failed .
For case (1), the eventual consistency is possible by using RetrySchdule or replaying the events and keep the event handler idempotent.
For case (2), it seems hardly possible . For example, a process needs the collaboration of aggregrate A,B and C. The business sequence is(not a long business) : commandA->commandB->commandC , what if commandC get failed ? In this case only commandC get rollback and commandA and commandB won’t as command is the transaction boundary in Axon. To solve the inconsistency, commandC can send compensation commands to A and B, but what if the version of A or B is NOT the same version as before ? the compensation command cannot continue in the case. Unless Axon keeps lock on A & B even after command A & B get finished , but I think it’s not true. For simple command bus maybe true, I’m talking about asynchronous command bus here. Whatever use Saga or not, it’s the same situation I guess.
Keeping both of the commandA and commandB are readonly command , or introduing certain distributed lock for the aggregrates’ collaboration can make sure the consistent.
I’m just starting to use Axon , probably there’s somthing I miss. What’s the axon’s suggested way to handling the case(2) ?