Hybrid Caching in Xperience

Hybrid caching would be awesome for scaling out. Overall if you code your site right then the speed of .net usually won't make too much of an impact on individual site caches, but this isn't always the case. There is also the consideration of when a site gets deployed and recycled, you may NOT want the cache to persist until all nodes are replaced, in case you cache something like HTML output that is now different with a different view.

Overall though, depending on how it goes, I would be very interested in what you are working on! Are you on the community slack channel? If not, shoot me an email ( `$"{{firstInitial}}{{LastName}}@gmail.com"` ) and i'll add you, then we can chat!

TLDR

Use Xperience's IProgressiveCache and move on to higher value work for your client.

HybridCache

HybridCache was created to solve problems when switching from IMemoryCache to IDistributedCache. You can basically think of it as a replacement for both with additional features.

In Xperience we have IProgressiveCache, which was created before HybridCache existed, but has many of the same capabilities.

Xperience does distributed caching through our web farm support, which coordinates cache eviction through web farm tasks synchronized through the database. This requires more database resources than an external cache, like Redis, but with much less complexity and doesn't require the cost of an additional external service.

Web farms also help with server restarts since a proxy server can send traffic to a different web farm server while one is restarting. Yes, the cache would need to be regenerated on the server after the restart, but externally cached data (ex: Redis) needs to be retrieved via HTTP request in this scenario anyway! You are effectively trading a SQL request for an HTTP request, but the point of a cache is to make these kinds of trades since most requests will be handled by cached data.

So, IProgressiveCache already supports L1 and L2 caching without Xperience developers needing to think about how it works.

What is the benefit of a Redis cache vs in-memory cache synchronized through SQL? Scalability - you can scale Redis independent of your SQL Server. But this is only a benefit if you need that scalability.

I have a custom solution for tagging cache entries in place already ... the only problem is HybridCache is still in preview

I have a few questions:

1. What problem are you trying to solve by creating a custom cache solution?
2. Is this something your solution requires?
3. Are you sure that IProgressiveCache won't work?
4. Does the custom cache solution truly help your client?
5. is using an "in preview" technology worth it given the engineering cost?

Umbraco adopted HybridCache because their existing caching solution was old and didn't handle their customer's needs - they couldn't really continue to use what they had.

If we see a benefit in switching to HybridCache in the future (I had a discussion with one of our architects about it in June 2024) then we'll probably do that in a way that is transparent to developers to avoid breaking changes, but as of now we just don't see the need because we already designed a good API and caching architecture.

FusionCache

Yep, it's an awesome library, but the same argument applies here - IProgressiveCache already does everything needed in most Xperience solutions with 0 extra engineering cost.

I would recommend sticking with Xperience's caching architecture for now.

Thanks so much for weighing in on this topic, there are definitely some points to take away and digest :)

Re; IProgressiveCache , correct me if I'm wrong but I believe it's not a truly distributed caching solution in the sense that cache items are being stored out of process. My understanding is that it still stores its items in the memory of each running instance, with web farms (SQL tables under the hood) being used to synchronise changes between them. I may be wrong on that though, I have not delved too deeply into the internals.

Does it store cache items in memory and in SQL, so that it doesn't have to regenerate the cache on a cold start/restart or when provisioning additional nodes?

If it does only store items in memory then I believe it can only be considered an L1 cache.

1. What problem are you trying to solve by creating a custom cache solution?

   1. To give a bit of background context, the project in question will be running in a kubernetes cluster and uses a horizontal pod autoscaler which can spin up/down new pods in response to increased requests or memory. Due to these scalability demands, we will need to maintain a high degree of availability and fast response times.
   2. Using this tiered cache approach gives us the benefits of a fast low latency in-memory cache, with the resiliency of a distributed cache store like redis, making it that much quicker to spin up new pods

2. Is this something your solution requires?

   1. This hasn't been strictly mandated by the client and I do believe we can get by using the out of the box IProgressiveCache although I can't ignore the benefits of a hybrid cache solution

3. Are you sure that IProgressiveCache won't work?

   1. I believe it will be a workable solution, although for scaling out, it will not result in faster uptime vs a hybrid cache

4. Does the custom cache solution truly help your client?

   1. In the grand scheme of things, it is unlikely to be something the client would notice. It's sometimes difficult to not fall into the trap of wanting to use the 'new shiny' things from a Dev perspective and whilst I can justify it myself, knowing the technical implications pros/cons etc... could we justify the added complexity, and possible tech debt, to the client is another question :)

5. is using an "in preview" technology worth it given the engineering cost?

   1. This is great question and is something I've raised internally. With HybridCache in particular, we don't know when it will be out of preview and it's missing tag support so I feel this API in particular is out of the question. FusionCache is also in preview, but is expected to be GA very soon: Release v2.0.0-preview-4 · ZiggyCreatures/FusionCache · GitHub
   2. I think if we were going to choose one of these, it will need to be FusionCache due to the tagging feature and the cache backplane

I've been playing around with FusionCache since I opening this thread, and have a rough working solution with these features:

• Cache invalidation for all content types via cache dependencies (tags in FusionCache)

  • Pages
  • Content items
  • Media files
  • Headless items
  • Settings key items
  • General object infos (via a custom 'provider' pattern)

• A custom <cache> tag helper which is backed by hybrid cache, again with support for cache invalidation via dependencies

• Custom output cache policy/store backed by FusionCache which also allows for setting dependencies

I think even if we decide to not go down this route, the code may be useful to others, even if it's just to experiment with.

If you or @Trevor Fayas would like to take a look I can pull it out of the project and into a public repo? :)