How to solve the issue of business validation inaccuracies caused by projection delays?

[yyc6698]

Enhancement Description

Currently, when attempting to create a draft for an application, there is a need to verify if the draft already exists. However, due to delays in updating the read models or projections, this verification can sometimes be based on stale data, leading to incorrect assessments or duplicate entries.

Current Behaviour

Axon Framework allows for eventual consistency in the projections of events. This approach, while efficient in many scenarios, can cause delays between the command handling that generates events and the update of the read models. In my case, when I create a draft and simultaneously check if it already exists, I face issues due to this delay.

Wanted Behaviour

I would like Axon Framework to provide a more robust solution for real-time verification against the read model, even when working within an eventually consistent system. This might include tools or patterns that help ensure that critical verifications, like checking for the existence of a draft, are accurate despite the inherent delays in the system.

[gklijs]

Why isn't it enough to check if the aggregate already exists?

[yyc6698]

Why isn't it enough to check if the aggregate already exists?

Aggregates are checked in Axon using the aggregate root ID. For instance, in current business processes such as approval documents, the aggregate root ID might be the approval document ID. However, to verify whether a person has initiated a specific approval, it is necessary to query using a different ID.

[gklijs]

Is initiating the approval not done via a command?

[yyc6698]

Is initiating the approval not done via a command?

This is accomplished through commands. In our business model, an individual in a specific unit can only initiate one approval document. This type of verification is currently done after receiving a command, by querying the repository. Once verified, an event to create the approval document is issued. However, due to delays in the repository, there is a possibility that the verification could be invalidated.

[gklijs]

Ok, this is getting too complex and out of scope. Typically you should be able to model the constraints in the aggregate. I don't think that's impossible in this case, but certainly could be challenging.

The read model could always be behind. What can be done is het the events/state of another aggregate. Although you still might run into problems as the other aggregate might be changed.

[michelkaeser]

Similar to what is suggested here https://www.axoniq.io/blog/2020set-based-consistency-validation you can always introduce strongly consistent projections in the write model as well via subscribing event processors and use these during business validation. Maybe that helps.

[yyc6698]

Similar to what is suggested here https://www.axoniq.io/blog/2020set-based-consistency-validation you can always introduce strongly consistent projections in the write model as well via subscribing event processors and use these during business validation. Maybe that helps.

We are currently utilizing this approach as well, but we have encountered an issue where transactions are not supported. In cases where exceptions occur during subscription tracking processing, events still get stored in the database, thereby failing to ensure transactional integrity.