Best practice for multiple write endpoints (cosmos db)

[Theodore Sackos]

Hi Folks,

I'm setting up geo-redundancy in Cosmos DB and enabling multiple write endpoints. I have nodes hosting my service across the US, and each will connect to the closest geographic write endpoint. I want each node to prefer the closest endpoint, and fallback on failures to other endpoints. 

Can you help me understand the best practices for setting up GremlinClient instances in .Net using Gremlin.Net?

I plan to create a gremlin client for each endpoint on service initialization, and walk the list of clients each time a query fails. Should I be worried about having those backup clients allocated and connections established?

Is it better to maintain a single GremlinClient and manage the synchronization around hot swapping the active client when that client's endpoint proves to be unhealthy?

Best,
Theodore

[Florian Hockmann]

I don't have much knowledge about Cosmos DB so I'll focus my answer on the parts of your question that are about Gremlin.Net.

Should I be worried about having those backup clients allocated and connections established?

The GremlinClient creates a ConnectionPool with 4 connections by default. So, I'd say that the resource usage should be quite small. (Assuming that you don't want to use this for something like tiny lambda functions where those resources would be created for each function call.) This number can also be configured though of course so you could also decrease this number if you want to.

A problem that was reported by some users of CosmosDB however is that CosmosDB closed connections if they were not used for a while. This could of course also affect you if you set up connection pools just as a backup and don't use them until an error occurs. For that reason, it could be a better option to only create a new GremlinClient (and therefore a new connection pool) when one endpoint becomes unreachable.

But this is now really specific to CosmosDB so you probably have to ask their team for guidance on this.