Strategies for Eventual consistency read models and triggers

A race condition is possible where a service has an Aggregate is triggered by a command before the related read model has been updated.

Are there any recommended strategies that can help mitigate against using stale read models?

As a rule of thumb there should be no need for an aggregate to reach out to the read model. Read models are for reporting purposes only most of the time. The aggregate stream contains enough information for making decisions and it is always fully consistent.

If you really need this (because more than on e aggregate is involved), you can store the Position of the ResolvedEvent in your read model. When you do an append, the WriteResult you get back has a LogPosition property. You can then plug this back in when querying your read model. If the last Position it saw is less than the one from your WriteResult you discard the query result and retry.

1 Like