I have the following scenario which I need to implement following the CQRS pattern:
This seems fairly straightforward, however my problem is between step 3 and 4, on step 3 I send a ApplyForDecision
command which will get a decision from a underwriting service, an event with the result of that decision is then sent to the BUS for the read store to later consume it and update the view tables with the decision result.
The problem is on the UI, how do I let the user know that the decision is being applied, since in CQRS the read model is not updated 'straightaway' how do I make the UI show that a decision is in progress and will 'soon' arrive?
I also need to give the user the ability to log out and log back in, since the decision may not have been applied yet, how do I make the UI show the 'pending decision screen'?
Eventual consistency is a characteristic of distributed computing systems such that the value for a specific data item will, given enough time without updates, be consistent across all nodes. Accordingly, the value across all nodes will be consistent with the last update that was made -- eventually.
Eventual consistency can be achieved by asynchronous and event-driven communication between microservices via messages and events brokers. Going back to the example we explained earlier. Every action in the process is basically an event that will be pushed to a certain queue.
Event-driven based systems that run at scale are not built in this approach, Instead, they force asynchronous broadcasts that remove the necessity of a global state with another kind of consistency called eventual consistency as the services communicate through different networks and clocks asynchronously.
The answer is to immediately raise an event indicating the decision has been applied for, update the read DB and redirect straight away to your pending decision screen whether or not the read DB has been updated by that time. Static text 'Pending decision you will be contacted' or something along those lines. They can refresh or come back later and more than likely will get the real data. Then when the decision has been decided, you have a DecisionMade event and update the read DB, send emails out, whatever the case, accordingly.
That's the trade off with eventual consistency you have to deal with in CQRS. Often when I've made changes to domain object properties on a form, I fake it in the immediate feedback the user gets while the back end does its chores. Yes, a little ugly but the users don't know that.
IMHO the solution would be to let your command emit an "ApplyForDecisionRequested" and an "ApplyForDecisionHandled" event, and update your read model accordingly.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With