How to handle concurrency by eventual consistency?

Question

How to handle concurrency by eventual consistency? Or I could ask how to ensure data integrity by eventual consistency?

By CQRS and event sourcing, eventual consistency means, that you put your domain events into a queue, and you set event handlers which are projections. Those projections update the read cache in an async way. Now if you validate using that read cache, you cannot be sure that the information you base your validation on, is still valid. There can be unprocessed (or unprojected?) domain events in the queue when you send your command, which can change the outcome of the validation. So this is just another type of concurrency... What do you think, how to handle these rare concurrency issues? Domain events are already saved in the storage, so you cannot do anything about them, you cannot just remove them from the event storage (because it supposed to be write only once), and tell the user in an email, that sorry, we made up our mind and cancelled your request. Or can you?

update:

A possible solution to handle concurrency by an event storage:

by write model

if
    last-known-aggregate-version < stored-aggregate-version
then
    throw error
else
    execute command on aggregate
    raise domain-event
    store domain-event
    ++stored-aggregate-version (by aggregate-id)

by read model

process query
if
    result contains aggregate-id
then
    attach read-cached-aggregate-version

by projection

process domain-event
read-cached-aggregate-version = domain-event-related-aggregate-version (by aggregate-id)

Hmm I read here: http://stackoverflow.com/questions/2916899/how-to-handle-set-based-consistency-validation-in-cqrs that ppl use sync private read caches for validation purposes. Is this really a legit solution? — inf3rno, May 24 '14 at 08:09
According to this: http://codebetter.com/gregyoung/2010/08/12/eventual-consistency-and-set-validation/ these kind of problems do not worth the effort, they simply have a too small business impact, so we can simply skip the failing events by the projections and maybe send a warning to an admin. — inf3rno, May 24 '14 at 08:21

score 1 · Accepted Answer · answered May 24 '14 at 10:26

1

As long as state changes you cannot assume anything will ever be 100% consistent. Technically you can ensure that various bits are 100% consistent with what you know.

Your queued domain event scenario is no different from a queue of work on a user's desk that still has to be input into the system.

Any other user performing an action dependent on the system state has no way to know that another user still needs to perform some action that may interfere with their operation.

I guess a lot is based on assuming the data is consistent and developing alternate flows and processes that can deal with these scenarios as they arise.

answered May 24 '14 at 10:26

Eben Roux

12,983
2
27
48

What do you suggest, should we completely ignore these kind of problems, and let the data integrity break? – inf3rno May 24 '14 at 23:12
1

Not at all. At each point that you handle a command your aggregate has to be consistent. If it is not then you may need to start off a process to handle that scenario, unless you are able to resolve the issue there-and-then. – Eben Roux May 25 '14 at 06:56

How to handle concurrency by eventual consistency?

1 Answers1