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