I read online that one should keep single instance of CosmosClient for a cosmos db account per application.

In my case, my app & cosmos db is deployed to multiple regions. Normally the app will read from the cosmos db in the same region.

However, in some scenario I want my app (whichever region it is running) to read from single cosmos db region, e.g. East US always.

Reason is, our cosmos db is on bounded staleness consistency, so data might not be replicated to other read regions instantaneously.

If I always write & read from the same region, I will be guaranteed to see the document there. So I am sacrificing latency for consistency in that scenario.

In order to achieve this, I have to specify which region I want to read from

var clientOptions = new CosmosClientOptions
                {
                    ApplicationRegion = "East US"
                };
                return new CosmosClient(_cosmosDbDataConnectionOptions.CosmosDbUrl, new DefaultAzureCredential(), clientOptions);

I want to use this CosmosClient for specific scenario.

In normal case, I will set ApplicationRegion = <app deployed region>

This requires me to have 2 CosmosClient for the same cosmos db account. Does it make sense to have 2 CosmosClient then ? Or is there any other recommended approach to this problem.

I looked up google and found out https://learn.microsoft.com/en-us/azure/cosmos-db/nosql/performance-tips-dotnet-sdk-v3?tabs=trace-net-core#sdk-usage . This recommends me to have 1 cosmos client per app. But in my case, I have to set read region differently per scenario.

CodePudding user response：

If the concern is about Consistency, then the SessionToken might help (Session Token from the Write on a Read call even if they are different client instances). If you have other scenarios where the logic is different and you, for whatever reason, want to change the read endpoint, yes, there is no way to flip it on a running client or say for a particular request, that you want it to go to another reagion.