Caching in ASP.NET Core

ASP.NET Core offers several caches, at different layers:

• IMemoryCache stores objects in the process. Fast and simple, but each instance has its own copy and a restart empties it.
• IDistributedCache stores bytes in a shared store such as Redis or SQL Server. Every instance sees the same entries, at the cost of a network hop and serialisation.
• HybridCache puts an in-memory layer in front of an optional distributed one and lets concurrent callers for one key in the same process share a single factory call. It ships as a separate NuGet package, Microsoft.Extensions.Caching.Hybrid, not in the shared framework; it was still a preview when .NET 9 shipped and became stable later, so check which version a project references.
• Output caching (AddOutputCache, UseOutputCache) stores whole responses on the server, with policies and tag-based eviction, and the server's policy alone decides what is cached. Response caching follows HTTP caching rules instead, so it is driven by Cache-Control headers and a client's request headers can bypass it.

Cache-aside and expiration

var product = await cache.GetOrCreateAsync($"product:{id}", entry =>
{
    entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10);
    entry.SlidingExpiration = TimeSpan.FromMinutes(2);
    return db.Products.FindAsync(id).AsTask();
});

Absolute expiration removes the entry a fixed time after it was created. Sliding expiration removes it after a period with no access, and every read pushes that deadline back. Combined, the entry goes at whichever comes first, so sliding never keeps an entry alive past the absolute limit. Sliding alone can keep a popular entry, and its stale data, forever. The model below applies the two rules to one entry read every 4 time units.

1public class Entry2{3    public int Created, LastAccess;4    public int? Absolute, Sliding;5 6    public bool Alive(int now) =>7        !(Absolute.HasValue && now >= Created + Absolute.Value) &&8        !(Sliding.HasValue && now >= LastAccess + Sliding.Value);9}10 11public static class Solution12{13    static string Trace(string label, Entry e, int[] reads)14    {15        var seen = new List<string>();16        foreach (var t in reads)17        {18            var alive = e.Alive(t);19            seen.Add($"t={t}:{(alive ? "hit" : "miss")}");20            if (!alive) break;21            e.LastAccess = t;                  // a hit slides the deadline22        }23        return label + " " + string.Join(" ", seen);24    }25 26    public static List<string> Run()27    {28        var reads = new[] { 4, 8, 12, 16, 20, 24 };   // created at t=029        return new List<string>30        {31            Trace("absolute 20:", new Entry { Absolute = 20 }, reads),32            Trace("sliding 5:", new Entry { Sliding = 5 }, reads),33            Trace("both:", new Entry { Absolute = 20, Sliding = 5 }, reads),34        };35    }36}

Stampedes

GetOrCreate on IMemoryCache does not lock. When a hot entry expires, every request that arrives before the first one finishes sees a miss and runs the factory, so the database receives a burst of identical queries at the worst moment. The model below uses a ConcurrentDictionary as the cache and forces four threads to miss together.

1using System.Collections.Concurrent;2 3public static class Solution4{5    static void RunFourCallers(Func<string> getProduct)6    {7        var threads = Enumerable.Range(0, 4).Select(_ => new Thread(() => getProduct())).ToList();8        threads.ForEach(t => t.Start());9        threads.ForEach(t => t.Join());10    }11 12    public static List<string> Run()13    {14        // Naive cache-aside: check, miss, then load. The barrier makes all four miss together.15        var naiveCache = new ConcurrentDictionary<string, string>();16        var naiveLoads = 0;17        var barrier = new Barrier(4);18        RunFourCallers(() =>19        {20            if (naiveCache.TryGetValue("product:1", out var hit)) return hit;21            barrier.SignalAndWait();22            Interlocked.Increment(ref naiveLoads);23            return naiveCache["product:1"] = "Widget";24        });25 26        // One Lazy per key: GetOrAdd returns the same stored Lazy to every caller.27        var lazyCache = new ConcurrentDictionary<string, Lazy<string>>();28        var lazyLoads = 0;29        var barrier2 = new Barrier(4);30        RunFourCallers(() =>31        {32            barrier2.SignalAndWait();33            return lazyCache.GetOrAdd("product:1", _ => new Lazy<string>(() =>34            {35                Interlocked.Increment(ref lazyLoads);36                return "Widget";37            })).Value;38        });39 40        return new List<string> { $"naive: {naiveLoads} loads", $"lazy: {lazyLoads} load" };41    }42}

ConcurrentDictionary.GetOrAdd hands every caller the one value it stored, so storing a Lazy<T> per key means only that instance's factory runs. IMemoryCache.GetOrCreate gives no such guarantee: two callers that miss together can each create and store their own Lazy, so it needs a per-key lock to get the same effect. HybridCache has this protection built in, within one process.

Common mistakes

• A cache key that omits an input of the query, such as the user or tenant id. The first user's data is then served to everyone who asks for the same key.
• Caching with sliding expiration only, so a frequently read entry never refreshes from the source.
• Using IMemoryCache behind a load balancer and invalidating on write. Only the instance that handled the write drops its copy; the others keep serving the old value until it expires.
• Setting SizeLimit on the memory cache without giving each entry a Size. Once a limit is set, an entry without a size cannot be added.

What interviewers ask

• In-memory or distributed cache for a service running on six instances? Trade-offs: consistency across instances and survival of restarts versus latency and serialisation; mention a two-level cache.
• Absolute versus sliding expiration? Definitions, and why sliding alone is risky; combine them.
• What is a cache stampede and how do you prevent it? Many concurrent misses running the same expensive factory; per-key locking, Lazy, HybridCache, or refreshing early.