Key isolation in multitenant setup

[sebbarg]

Thanks for an awesome cache!

I have a multitenant setup using Autofac to host per-tenant child DI scopes:

• I must make sure that both level 1 and level 2 caches isolate key names so that they don't overwrite each other.
• New tenants and their child scopes can be created (and destroyed) on demand.

I see two paths forward:

1. Register a named cache once per tenant in their respective scopes and enable WithCacheKeyPrefix;
2. Register a single cache in the global (root) scope and create a cache wrapper that class that makes sure all keys are prefixed when calling Set, Get, etc. This wrapper class is then registered in each tenant scope.

I prefer (1) for simplicity, but I worry that it will create too many redundant instances of whatever makes FusionCache run. (2) is a pain because I need to wrap the public API and maintain it going forward.

Thoughts?

[jodydonetti]

Hi @sebbarg

Thanks for an awesome cache!

You're welcome, happy you're liking it 🙂

I have a multitenant setup using Autofac to host per-tenant child DI scopes:

• I must make sure that both level 1 and level 2 caches isolate key names so that they don't overwrite each other.
• New tenants and their child scopes can be created (and destroyed) on demand.

I see two paths forward:

1. Register a named cache once per tenant in their respective scopes and enable WithCacheKeyPrefix;

Regarding the resources usage: it's possible to share the same underlying L1 (memory cache) and L2 (distributed cache), and by using a different CacheKeyPrefix the cache keys will not collide.
Having said that, the main problem I see is that any FusionCache named cache registration must be done at startup, and cannot be done at runtime on demand, so I don't think it will work for dynamically created tenants.

2. Register a single cache in the global (root) scope and create a cache wrapper that class that makes sure all keys are prefixed when calling Set, Get, etc. This wrapper class is then registered in each tenant scope.

Probably better.

I prefer (1) for simplicity, but I worry that it will create too many redundant instances of whatever makes FusionCache run. (2) is a pain because I need to wrap the public API and maintain it going forward.

Understandable. Maybe a common ground would be to use a centralized utility method to generate the cache keys, such that the method force the selection of a TenantId?

Meanwhile, I'll see if I can come up with something else.

[sebbarg]

Thanks for the feedback! I'll go with option 2 for now, all good :)

[Amorganskate]

@sebbarg I also have a platform that supports about 100 individual tenants currently, we have unique keys to identify each tenant and we use that key to append to cache-prefix.

[sebbarg]

OMG, I didn't realize how many overloads there are 😬