FusionCache: a hybrid cache for .NET with stampede protection and fail-safe

The problem FusionCache solves: one cache stampede per cold node

A plain memory cache is simple until you run more than one instance of a service. Then each instance warms independently, each instance misses the same keys at the same moment, and each instance calls the same downstream database or API. That is a cache stampede, and it usually shows up as a latency spike right after a deploy or a restart. FusionCache exists to make that situation manageable without hand-written locking code.

The README frames the origin of the project around exactly this kind of experience: it says FusionCache was born after years of dealing with memory, distributed, hybrid, HTTP, CDN, browser and offline caches. The audience is therefore .NET teams that already understand they need a cache and now need the failure behaviour around it. The topics list on the repository is blunt about the target: async, cache-stampede, hybrid-cache, multi-level.

If you only ever run one process and your data fits in memory, this is a heavier tool than you need. The value shows up when nodes multiply.

L1, L2 and the backplane: the actual data flow

FusionCache is a hybrid cache, which the README describes as working transparently either as a normal memory cache (L1) or as a multi-level cache (L1+L2). The L1 layer is in-process memory. The L2 layer is any implementation of the standard IDistributedCache interface, which means the distributed tier is not a FusionCache-specific product but whatever you already use.

Reads go to L1 first. On a miss, the distributed tier is consulted, and a hit there can repopulate the local layer, which is what gives the better cold starts the README mentions. Writes and evictions need to reach the other nodes, and that is the job of the optional backplane, documented separately in docs/Backplane.md: in a multi-node scenario it notifies other nodes about changes so they stay in sync. Without a backplane, each node's L1 can go stale relative to the others until its own entry expires.

Around that core sit the resiliency features: cache stampede protection at both the local and distributed level, fail-safe, soft and hard timeouts, eager refresh, tagging, and observability through logging and OpenTelemetry. These are documented as separate pages under docs/, which is a reasonable sign that each one has its own semantics rather than being a single toggle.

Getting FusionCache from NuGet and writing a first call

FusionCache is distributed as the NuGet package ZiggyCreatures.FusionCache, which the README's badge links to on nuget.org. The repository does not spell out an install command in the text of the README; it points instead to a Quick Start section, to docs/AGentleIntroduction.md for the overall concepts, and to docs/StepByStep.md for a guided walkthrough. So the concrete starting point is the package page plus those three documents, and the first thing to read after installing is the Options page, docs/Options.md, because the global and per-entry options are where most of the behaviour lives.

The README does not print a full code sample in the section reproduced here. What it does state is the shape of the API surface: a get-or-set style call is the central entry point, the project exposes async operations (the repository is tagged async), and the README lists GetOrSetAsync among the phrases people search for around it. The README also states that any IDistributedCache implementation can be used as the optional second level, documented in docs/CacheLevels.md, and that a backplane is optional and documented in docs/Backplane.md.

What you should expect after wiring it up is the behaviour described in those pages rather than anything this article can promise: a cold key runs your factory once, a warm key returns the stored value, and the multi-level configuration decides whether a miss is also checked against the distributed tier. Verify each of those against the docs before you rely on them.

Cache stampede protection, fail-safe and the cost of both

The two features that most distinguish FusionCache from a plain cache wrapper are stampede protection and fail-safe, and both trade behaviour for safety in ways worth understanding before you enable them.

Cache stampede protection means that when many callers ask for the same missing key at once, the work is coordinated rather than duplicated. The README describes it as automatic, and as available both locally on a single node and distributed across multiple nodes. The distributed variant is the interesting one: it implies coordination through the distributed tier or the backplane rather than only an in-process lock, which is what makes it useful during a cold start across a fleet.

Fail-safe is described as a mechanism to avoid transient failures by reusing an expired entry as a temporary fallback. The trade-off is explicit in that sentence: during a failure window, callers can receive data that is past its expiry. That is usually the right call for a product listing or a profile, and the wrong call for anything where staleness has a correctness or compliance cost. The README does not document rollback for either feature, so treat the choice as a design decision rather than a runtime switch you flip under pressure.

Soft and hard timeouts address a related failure: a slow factory or a slow distributed cache slowing down the application. The README's claim is that no data is wasted, which suggests a timed-out operation is not simply discarded. That is a design promise worth reading in docs/Timeouts.md rather than assuming.

Where FusionCache is the wrong tool

FusionCache is a library, not a cache server. If your operational model assumes a standalone cache process you can monitor, resize and fail over independently, FusionCache does not give you that; it gives you code that talks to a distributed cache you still have to run. The L2 is deliberately abstracted behind IDistributedCache, so questions about eviction policy, memory limits and persistence belong to whatever implementation you plug in, not to FusionCache.

It is also .NET-only. The repository is C#, the package targets NuGet, and nothing in the README suggests a port. A polyglot stack cannot share this abstraction across languages.

There is a subtler cost: the feature set is large. Named caches, tagging, clear, adaptive caching, conditional refresh, background distributed operations and the Microsoft HybridCache integration each carry their own options, and the README points to a dedicated Options page because of it. Teams that want a cache with three knobs will find this one has considerably more, and the failure modes of a misconfigured timeout or fail-safe window are not obvious from the surface API.

FusionCache compared with Microsoft HybridCache and plain IDistributedCache

The closest real alternative is the HybridCache abstraction from Microsoft, and FusionCache's answer is not to compete with it but to implement it. The README describes a "powerful integration" documented in docs/MicrosoftHybridCache.md, where FusionCache can be used as an implementation of that abstraction while adding extra features. So the difference in approach is one of scope: Microsoft's abstraction defines a common surface, while FusionCache supplies an implementation plus stampede protection, fail-safe, backplane sync, tagging and the rest. If you want the abstraction and nothing more, you do not need this package. If you want the abstraction plus the resiliency behaviour, the integration is the path.

The other comparison is against using IDistributedCache directly. That is a lower-level interface with no stampede protection, no fail-safe, and no local layer unless you build one. It is also the layer FusionCache sits on top of, which means adopting FusionCache does not remove your distributed cache, it adds coordination and a local tier in front of it. The searches people run around this project, fusioncache vs redis and fusion cache vs memory cache, both miss that relationship: Redis is typically the L2, and the memory cache is the L1.

Licence, maintenance and upgrade cost

FusionCache is MIT licensed, and the README carries the MIT badge linking to opensource.org. MIT is permissive: it allows commercial use and modification, and the practical implication is that you can ship it inside a closed product. That is a statement about the licence text, not legal advice; if your organisation has a policy on third-party dependencies, run it through that process.

The repository is not archived, and the last push was on 2026-09-22, the same day as the v2.9.0 release. Releases are frequent: v2.7.2 on 2026-08-26, v2.8.0 on 2026-09-13, v2.9.0 on 2026-09-22. That cadence is the upgrade cost. A library moving through minor versions this quickly will occasionally change option names or defaults, and the README's structure of separate docs per feature means there is no single changelog page to skim. Pin an explicit version in your project file and read the release notes before bumping.

One more signal worth weighing: the README states that FusionCache is used by Microsoft itself in products like Data API Builder. That is a statement about adoption, not about fitness for your workload.

Editorial conclusion

Adopt FusionCache if you run a .NET service on more than one node, already have a distributed cache, and want stampede protection and fail-safe without writing that logic yourself. Skip it if a single-process MemoryCache covers your load, if your stack is not .NET, or if you need a cache server you can operate directly, since FusionCache is a library and never a server. Before committing, verify three things in your own environment: that your IDistributedCache implementation behaves under the soft and hard timeout settings you choose, that your serialization choice round-trips every type you plan to cache, and that the backplane you pick is actually available in your deployment. The README's own Step By Step guide is the fastest way to check the first two.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. ZiggyCreatures/FusionCache on GitHub