Cache Regions?

[jodydonetti]

A discussion has started around the possibility of introducing the concept of "cache regions" (see #33 ): there, it is possible to see the potential problems involved, and some possible ways around those.

Thanks to @jasenf for bringing that up and providing his experience on the subject.

This issue will be used to track the hypothetical design, limitations and feature set around regions.

[aKzenT]

I was reading the discussion on #33 and wanted to add some additional thoughts. First of all the concept of cache regions and specifically being able to selectively flush entire regions is also very important to the projects I'm working on. This includes being able to flush redis entries, which as you mentioned in the discussion is not easy to do in a scalable manner.

Besides scanning the entire redis cache for keys to delete, there are at least two other ways I can think of to implement this that we have used ourself with more or less success.

The first option is to maintain a separate hashset on redis for the cache region itself that contains all known keys belonging to the cache region. Whenever a new key is written it is also added to the hash set. On flush, you only iterate through the members of the cache group and then delete the keys stored there.

The second option is using some kind of soft expiration. Instead of deleting the cache group, you could notify all clients (e.g. via backplane) that all entries belonging to a named cache group that are older than timestamp XXX are to be considered stale.

I think the second option is particulary interesting because it would still allow a fail-safe mechanism to work. E.g. if the database goes down right at the time we are flushing the cache, it would be unfortunate.

What are your ideas on that?

In fact, I'm right now struggling trying to implement one of these methods on top of Fusion-Cache and not sure how to do this.

[aKzenT]

To bring up another idea:

While using FusionCache in a larger project, that also uses dependency injection, I noticed that a single fusion cache instance is not enough for our purposes as for example we require different serializer-configuration for some caching content than for others. What I ended up using was a model similar to HttpClient/IHttpClientFactory. Instead of registering a single fusion cache instance, I added a service collection overload that allows registering named cache instances.

Internally this just registers a new fusion cache instance each time you call it and configures the name of that cache to match the provided name. For the cache options I use the integrated functionality to register named IOptions instances with the same name. I then created a IFusionCacheResolver interface and implementation that gets injected with a list of all registered fusion caches and has a Resolve-Method to return the fusion cache with a matching name. Instead of injecting IFusionCache instances directly, I inject the IFusionCacheResolver which the class can use to resolve a specific name by cache.

For my needs, this turned out to be a good design for "cache regions" as well. Basically in my solution, every cache region is now just a named FusionCache-instance and using a plugin I implemented a kind "Flush" similar to the method described in my other post.

[jodydonetti]

Agree! That is probably the best way to approach this.
So much so that I'm actually already experimenting with an IHttpClientFactory+ named caches approach already ;-)

See here #90 (reply in thread)

[aKzenT]

That sounds great. Let me know if you have an API to share and I will gladly review.

[jodydonetti]

Hi @aKzenT , I just created an issue to track the design and development of the Named Caches feature.

If you'd like, please take a look there and let me know what you think.

Thanks!

[jodydonetti]

UPDATE: it is happening 🥳

Any help would be appreciated!

[jodydonetti]

Hi all, v2.0.0-preview-1 is out 🥳
This includes Tagging and Clear() support!

🙏 Please, if you can try it out and let me know what you think, how it feels to use it or anything else really: your contribution is essential, thanks!