**Single Region Writes** and **Multi-region Reads**

[dnitsch]

We are continuously addressing and improving the SDK, if possible, make sure the problem persists in the latest SDK version.

This is more of a question rather than a bug.

In a scenario where:

• dev stage uses single region read/writes (this is absolutely fine)
• pre-prod stage uses single region writes and multi-region reads - this is the only way seemingly to achieve strong consistency across regions...

Deploy 2 of the same apps in 2 different regions and ensure writes from both happen into the single RegionX and reads from each app happen inside the region they are deployed in - i.e. adhering to the ApplicationRegion option.

Is this possible by extending the options of the actual Azure SDK client - or an extension through this repository?

To Reproduce
Steps to reproduce the behavior. If you can include code snippets or links to repositories containing a repro of the issue that can help us detect the scenario it would speed up the resolution.

Expected behavior

The ability to provide read and write endpoints

Actual behavior

Writes fail in the region where there are no writes enabled with 503

Environment summary
SDK Version: 3.32.2
OS Version (e.g. Windows, Linux, MacOSX): Linux/Mac

Additional context
Add any other context about the problem here (for example, complete stack traces or logs).

[IEvangelist]

Hi @dnitsch - I converted this to a discussion as that seems more appropriate than an issue.

So that I understand this correctly, you're asking for the ability to specify that read-only regions prevent writes from the SDK perspective? We do have an IReadOnlyRepository<TItem> interface, so that might not be too difficult, assuming there are some options to infer usage with.

[dnitsch]

correct me if I am wrong, but there would be no need to have separate ServiceImpl (this is mainly being lazy but also thinking about backwards compatibility) and just the read/write clients so that it can runtime, potentially strategy, select the correct client if present or fallback to default if only a single instance is provided.

Haven't dug through the code but IBatchRepo seems to only be doing write operations.

[IEvangelist]

perfect thanks @IEvangelist - are you happy with a PR (most probably from some of the more .net focused members ;) ) or is that something you usually handle yourself?

I LOVE COMMUNITY PRs, I tend to not have nearly enough time to do it all alone. 🤓

[IEvangelist]

correct me if I am wrong, but there would be no need to have separate ServiceImpl (this is mainly being lazy but also thinking about backwards compatibility) and just the read/write clients so that it can runtime, potentially strategy, select the correct client if present or fallback to default if only a single instance is provided.

Haven't dug through the code but IBatchRepo seems to only be doing write operations.

I was imagining (in my head) that this could all be done with the DefaultCosmosClientProvider and internally somehow being smarter about how it returns a client. But I'd have to dig in more.

[dnitsch]

perfect thanks @IEvangelist - are you happy with a PR (most probably from some of the more .net focused members ;) ) or is that something you usually handle yourself?

I LOVE COMMUNITY PRs, I tend to not have nearly enough time to do it all alone. 🤓

Ok sweet I can open a feature request and a PR if you tag it as help wanted/welcomed :).

[mumby0168]

Hi, just catching up on this yes I think we can happily store my clients, I think the multi region should be opt-in via the options and then we may pass some configuration around the read/write configuration and the region details.

Then I agree with @IEvangelist that the abstraction for this probably best sits in the DefaultCosmosClientProvider or maybe even a new implementation of that that is registered with multi region support. Maybe MultiRegionCosmosClientProvider ?

[dnitsch]

Sorry about the late follow up on this, I'll try to logically split the discussion above based on some further findings and hopefully to help others finding this later on.

• Single Region Write/Multi region reads
  Multiple clients for the purposes of satisfying single write/multiread scenario, is actually in the end a non issue. Our problem were stale credentials managed incorrectly by a aadpodidentity (v2) and once everything was deleted and re-created this started to work again, without errors - but would consider an issue isolated to an AKS set up.

If possible use the latest AKS managed identity operator

The SDK, used by this repo, the v2 version - manages this internally and passing in additional config especially setting a few extra params on the ConnectionPolicy - namely PreferredLocations and UseMultipleWriteLocations => false, will do the trick for this scenario as the SDK under the hood uses a conventional endpoint interpolation by appending the cannonical region name to the cosmosDB account name -> https://$COSMOS_ACC_NAME-$PREFERRED_REGION.documents.azure.com:443/ for the underlying client to perform the actual data operations.

• Legitimate MultiClient Setup
  There maybe legitimate use case when a service will need to talk to separate Cosmos Accounts and DBs -> containers within them, e.g. in a fan-out type scenario for persistent storage, the underlying resiliency/geo-distribution modes of each account are handled implicitly as I now know 🤦 .
  However, for these cases @mumby0168's suggestion of potentially creating a separate instantiation via MultiRegionCosmosClientProvider seems maybe the best / cleanest approach.

@IEvangelist happy to submit it as a formal idea via the discussion tab - if you think it's worth developing further and adding to the lib as re-useable piece of functionality.

[IEvangelist]

Hi @dnitsch,

happy to submit it as a formal idea via the discussion tab - if you think it's worth developing further and adding to the lib as re-useable piece of functionality.

Let's move forward, yes, please! Looking forward to it.