Handling eventual consistency can be quite hard. Sometimes you want data to be up-to-date, or fail the query.
Once #3087 is implemented, it will become easier to know to "how far" an action generated events, as the position would be returned.
If we could combine that information with an API change on the QueryBus/QueryGateway/QueryMessage to carry the position, there would be a window of opportunity to provide "at least up-to-date" semantics out of the box.
Implementation suggestion
Based on a property in the GenericQueryMessage, (e.g. of type Instant) we can check whether the EventProcessor is up-to-date or at least at the provided date.
Challenges
We need to know the segment to check
The TokenStore does not allow checking the token without claiming. So, queries would have to be routed to the same instance, or this should be relaxed.
Can we tell if the EventProcessor has caught up for sure?
Description
Handling eventual consistency can be quite hard. Sometimes you want data to be up-to-date, or fail the query.
Once #3087 is implemented, it will become easier to know to "how far" an action generated events, as the position would be returned. If we could combine that information with an API change on the
QueryBus/QueryGateway/QueryMessageto carry the position, there would be a window of opportunity to provide "at least up-to-date" semantics out of the box.Implementation suggestion
Based on a property in the
GenericQueryMessage, (e.g. of typeInstant) we can check whether theEventProcessoris up-to-date or at least at the provided date.Challenges
TokenStoredoes not allow checking the token without claiming. So, queries would have to be routed to the same instance, or this should be relaxed.EventProcessorhas caught up for sure?