All Types of Caching in .NET: When to Use Each (Deep Dive, Part 2)
A deep dive into the last two caching options in .NET: FusionCache, which adds a Redis backplane, fail-safe and eager refresh on top of the hybrid L1+L2 model, and Output Cache, which stores full HTTP responses with tag-based eviction. The article covers the packages, DI wiring and the pitfalls of each.
Key points
- FusionCache adds a Redis pub/sub backplane that drops the L1 copy on other instances after an invalidation, fixing the stale-memory problem of HybridCache.
- Fail-safe, soft/hard factory timeouts and eager refresh keep an API answering from the last known value when a database or dependency fails.
- Packages needed: ZiggyCreatures.FusionCache, the System.Text.Json serializer, the Redis backplane and Microsoft.Extensions.Caching.StackExchangeRedis.
- Output Cache stores the whole HTTP response, so on a hit neither the handler nor the database runs; policies use Expire(), SetVaryByRouteValue() or SetVaryByQuery() and Tag().
- Eviction by tag with IOutputCacheStore.EvictByTagAsync() works across instances only when you add Microsoft.AspNetCore.OutputCaching.StackExchangeRedis.
- Output Cache handles GET/HEAD and 200 responses only, and skips authenticated requests unless you vary by user, which lowers the hit rate.
Part two of Anton Martyniuk's caching series moves past IMemoryCache, IDistributedCache, Redis and Microsoft's HybridCache to the two options that cover most production needs: FusionCache and Output Cache. FusionCache is a third-party hybrid cache with the same L1 memory plus L2 distributed shape and stampede protection, and it adds what HybridCache lacks - a backplane that pushes invalidation messages to every instance over Redis pub/sub, fail-safe fallbacks when the factory throws, soft and hard timeouts, and background eager refresh for hot keys.
The article shows the required packages (ZiggyCreatures.FusionCache plus the System.Text.Json serializer, Redis backplane and Redis distributed cache), the DI wiring with FusionCacheEntryOptions, and an AsHybridCache() adapter so existing handlers that inject HybridCache keep working. The Output Cache half covers named policies with Expire(), SetVaryByRouteValue() and Tag(), the CacheOutput() endpoint call, tag eviction through IOutputCacheStore.EvictByTagAsync(), and the package for a shared Redis store. It warns that authenticated requests bypass caching by default and that response caching is obsolete.
Real-world use
- A read-heavy shipment or product API running on several instances that must not serve stale data after an update.
- A public catalog endpoint where the handler and database should not run at all on repeat requests.
- An API calling a slow downstream service that needs a fallback value when that service is unavailable.
- A multi-instance deployment where a write handler must evict cached list responses for every instance at once.
Why it matters
Choosing between FusionCache and Output Cache decides whether you cache data or whole responses, and whether your instances invalidate each other or drift apart. The backplane and Redis output store are the difference between a cache that stays correct under load and one that quietly serves stale data.