CosmosDb multi-region writes and creating globally unique value

Val Tortola Luis 40 Reputation points
2025-02-05T21:36:52.23+00:00

Hi!

I am trying to understand how to deal with conflicts when using multi-region writes.

Imagine I am trying to create a Twitter clone and I have to ensure that when a user creates an account, it also select an unique user handle (a unique key like username ).

In a single region I would just have a container with no indexing and then create that value as a partition key, if I succeed it means that there was not another handle with that value and from this point nobody else will be able to add it.

But when thinking in multi-region writes, two persons in different regions could indeed add the same handle. Then the conflict resolution strategy would need to deal with it. But the only conflict resolution possible here is to delete one of them. But this is happening asynchronously after both persons successfully created their accounts, so one of them would get a bad surprise the next time they log in.

As far as I understood, there is no way to have Strong consistency across multiple write regions.

After thinking for a while about this problem I think there is no solution possible using multiple write regions. The only solution would be to have this container in an account with a single write region, and although the client could do a "tentative query" to another read-only region to see if a given handle is already taken, in the final step to actually take it I must force the client to do the final write operation in that particular region. Consistency levels here only help to define how close to reality is the "tentative query", but that is all.

Does this reasoning make sense?

Many thanks.

Azure Cosmos DB
Azure Cosmos DB
An Azure NoSQL database service for app development.
1,753 questions
0 comments No comments
{count} votes

Accepted answer
  1. Marcin Policht 35,360 Reputation points MVP
    2025-02-06T02:42:09.87+00:00

    AFAIK, your reasoning is correct. When using multi-region writes, you lose the ability to enforce strict uniqueness constraints at the point of ingestion due to the lack of strong consistency across regions. Effectively, two users in different regions could successfully create an account with the same handle, leading to conflicts that must be resolved asynchronously.

    Multi-write regions allow writes to happen independently in different regions. Conflict resolution is applied after the fact. The only way to enforce strict uniqueness at the time of write is through strong consistency, which is not possible across multiple write regions. Even if a conflict resolution strategy (like "last write wins") is used, it happens after both writes have already been acknowledged, meaning one user will have their handle removed.

    Your proposed solution i.e. having a single write region for handle registration while allowing reads from multiple regions seems to be the most viable approach. This way, since all handle registration requests go to a single region, the uniqueness check can be enforced at write time. Clients in different regions can perform tentative checks against read replicas, but the final decision is made in the single authoritative write region. The single write region can enforce strong consistency locally, ensuring no two users get the same handle.

    If you really want multi-region writes, you might want to consider an alternative approach that leverages an external coordination mechanism (e.g., a globally reachable API) that acts as the single source of truth for handle registration.


    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.