Cosmos cliënt per DB account?

[Mortana89]

Hi,

We have a B2B multi tenant application, and use currently one DB account and several databases/containers per tenant.
Since serverless is out we've been using it for some other application, and are going to migrate our head system to serverless as well. More specifically we'll go for complete isolation by using a single DB account per tenant.
We won't have thousands of tenants so there should be no issue (we're aware of the current limits).

Our current design is a factory which returns the correct container/database based on a tenant ID and container name. Behind the bonnet we use a singleton Cosmos Cliënt, and have some concurrent dictionaries to speed up retrieval for the containers.
Now, with an account per tenant approach, do we create a cosmos cliënt per tenant, and keep these in our cache as well? Or will this cause any problems?

[ealsur]

If you need to handle multiple accounts, then there isn't a better option than having one client per account.

The only problem is, each client will have it's own independent set of connections. If you run the app in an environment where number of connections is limited (like App Service), and you are handling multiple tenants, you might reach a point where you'd exhaust available connections.

[Mortana89]

Thanks! We're running on a VMSS within Service Fabric, so I think we don't have a real limit?
We could implement a sort of eviction policy to evade stale clients if needed. At what Point would we see any issues?
In any case, it won't go fast above 30-50 clients very soon, before we might even consider regional VMSS instances and thus their own cosmos clients Serving regional tenants

[ealsur]

At what Point would we see any issues?

Hard to know, it depends again on the environment. You could keep track of when you fetch the client instance from the Dictionary, and have a background thread that disposes clients not used in X time.