How to implement semantics of serializability in eventually consistent system?

by Pavel Voronin   Last Updated September 26, 2018 11:05 AM

In a distributed asynchronous system serializability cannot be achieved, but we still have to somehow provide the semantics.

Consider quite natural requirement that user must have unique email or no email at all. (Option of not having an email implies that we cannot use email as a unique actor's address.)

What should happen when system receives two concurrent requests for creating user with same email? One of them should eventually fail.

We could query all user actors asking them whether anyone has same email, but due to concurrency none of the two new users may be created at that time. Same problem exists for email update.

How to achieve these functionality without compromising scalability and performance? How do I let client now that its request failed?



Related Questions


What is eventual consistency?

Updated September 26, 2017 14:05 PM

Domain driven design with eventual consistency

Updated July 27, 2015 17:02 PM

Domain Events Groupping/Buffering

Updated August 23, 2016 08:03 AM

Saga's and Query model transaction ordering

Updated August 27, 2018 23:05 PM

DDD - Domain events vs application events

Updated October 08, 2018 18:05 PM