Caching Strategies

By the end of this lesson you'll be able to make a .NET app dramatically faster by serving data from a cache instead of recomputing it or hitting the database every time — using the cache-aside pattern, IMemoryCache, and Redis, with the right expiry and invalidation so your data never goes stale.

1. The Cache-Aside Pattern

Almost every cache you'll write follows one shape, called cache-aside (or "lazy loading"): look in the cache first; on a hit return the stored value; on a miss compute it, store it, then return it. A "hit" means the value was already there; a "miss" means it wasn't and you had to do the slow work. Before reaching for any library, it's worth seeing the whole pattern in plain C# with a Dictionary<int,int> standing in for the cache — once you can write it by hand, every caching API is just a tidier version of this. Read the worked example, run it, then you'll write one.

using System;
using System.Collections.Generic;

class Program
{
    // The cache: a fast in-memory lookup of id -> already-computed result.
    static Dictionary<int, int> cache = new Dictionary<int, int>();

    // An "expensive" computation we want to avoid repeating.
    // Pretend this hits a database or calls a slow API.
    static int ExpensiveSquare(int n)
    {
        Console.WriteLine($"  ...computing {n} squared (slow!)");
        return n * n;
    }

    // CACHE-ASIDE: look in the 
...

Your turn. This GetLength method is the same cache-aside shape, but two pieces are missing. Fill in the ___ blanks so it returns the cached value on a hit and stores the result on a miss, then run it.

using System;
using System.Collections.Generic;

class Program
{
    static Dictionary<string, int> cache = new Dictionary<string, int>();

    static int CountLetters(string word)
    {
        Console.WriteLine($"  ...counting letters in '{word}' (slow!)");
        return word.Length;
    }

    // 🎯 YOUR TURN — finish the cache-aside lookup, then run it.
    static int GetLength(string word)
    {
        // 1) Return the cached value if it's already there.
        if (cache.TryGetValue(word
...

2. Measuring Hits vs Misses

A cache is only earning its keep if most requests are hits. The hit ratio — hits divided by total lookups — is the number you watch in production: a low ratio means you're caching the wrong things or expiring them too quickly. You can measure it the same way you'd build it: count a hit when the value was already cached and a miss when you had to compute it. Fill in the two blanks so the counters move correctly, then run it.

using System;
using System.Collections.Generic;

class Program
{
    static Dictionary<string, string> cache = new Dictionary<string, string>();
    static int hits = 0;     // counts how often the value was already cached
    static int misses = 0;   // counts how often we had to compute it

    static string Lookup(string key)
    {
        // 🎯 YOUR TURN — record a HIT or a MISS on each lookup.
        if (cache.TryGetValue(key, out string value))
        {
            // 1) It was in the ca
...

3. In-Memory Caching with IMemoryCache

In a real .NET app you don't hand-roll a Dictionary — you inject IMemoryCache (registered once with builder.Services.AddMemoryCache()). It's the fastest cache because it lives right in your server's RAM, but it's not shared between servers and it's lost on restart. Its GetOrCreate method is the cache-aside pattern in a single call: it returns the cached value, or runs your factory delegate on a miss and stores the result for you. Note this snippet is application code that needs the ASP.NET packages and a database, so read it rather than running it here.

using Microsoft.Extensions.Caching.Memory;

// GetOrCreate is the cache-aside pattern built in: it checks the cache,
// and only runs your factory delegate (the slow work) on a MISS,
// storing the result so the next call is a HIT.
public class ProductService
{
    private readonly IMemoryCache _cache;
    private readonly AppDbContext _db;

    public ProductService(IMemoryCache cache, AppDbContext db)
    {
        _cache = cache;
        _db = db;
    }

    public Product? GetProduct(int id)
...

4. Absolute vs Sliding Expiration

Nothing should live in a cache forever, or it slowly drifts out of sync with the truth. Absolute expiration kills an entry at a fixed time no matter how busy it is — a hard freshness ceiling. Sliding expiration resets the timer every time the entry is read, so popular data stays warm and only idle data is dropped. The danger of sliding alone is that a constantly-read key could live indefinitely and grow stale — so the safe default is to set both: sliding to keep hot data, absolute to cap how old any value can ever get.

using Microsoft.Extensions.Caching.Memory;

// Two ways an entry can expire:
//   ABSOLUTE — dies at a fixed time, no matter how often it's used.
//   SLIDING  — the timer RESETS every time the entry is read; it only
//              dies after a quiet gap with no access.
// Use BOTH together: sliding keeps hot data warm, absolute caps how
// stale any value can ever get.
var options = new MemoryCacheEntryOptions()
    .SetSlidingExpiration(TimeSpan.FromMinutes(5))    // reset on each read
    .S
...

5. Invalidation — Killing Stale Data

Expiration handles staleness over time, but when you change the underlying data you can't wait for a timer — the cached copy is wrong now. Invalidation means removing (or replacing) the cached entry the instant its source of truth changes, usually right after the database write that changed it. The pattern is simple: write to the database, then _cache.Remove(key) so the very next read misses and reloads the fresh value.

using Microsoft.Extensions.Caching.Memory;

public class ProductService
{
    private readonly IMemoryCache _cache;
    private readonly AppDbContext _db;

    public ProductService(IMemoryCache cache, AppDbContext db)
    {
        _cache = cache;
        _db = db;
    }

    public Product? GetProduct(int id) =>
        _cache.GetOrCreate($"product_{id}", entry =>
        {
            entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10);
            return _db.Products.Find(id);
 
...

6. Distributed Caching with Redis

The moment your app runs on more than one server, in-memory cache becomes a liability: each server caches its own copy, so they disagree and an invalidation on one never reaches the others. A distributed cache solves this — Redis is a separate, fast key-value store that every server reads from and writes to, so they all see the same data and it survives a restart. The trade-off: Redis stores bytes, so your objects must be serialised (typically to JSON) on the way in and deserialised on the way out, and each access costs one small network hop.

using Microsoft.Extensions.Caching.Distributed;
using System.Text.Json;

// Program.cs — register Redis as the distributed cache.
// In-memory cache lives inside ONE server's RAM; a distributed cache
// (Redis) is a separate shared store every server reads from, so all
// your instances see the same data and it survives an app restart.
builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = "localhost:6379";
});

public class SessionStore
{
    private readonly IDist
...

7. Preventing a Cache Stampede

Here's the failure mode that bites teams in production: a popular cache entry expires, and in that instant dozens or hundreds of in-flight requests all miss at once and pile onto the database together. That's a cache stampede (or "dogpiling"), and it can take a database down precisely when traffic is highest. The fix is to let one request rebuild the entry while the rest wait on a lock — a SemaphoreSlim does this cleanly. Always re-check the cache after acquiring the lock, because another thread may have already filled it.

using Microsoft.Extensions.Caching.Memory;

// CACHE STAMPEDE (a.k.a. "dogpiling"): a hot key expires, and dozens of
// requests all MISS at the same instant and hammer the database together.
// Fix: let ONE request rebuild the entry while the others wait.
public class CatalogService
{
    private readonly IMemoryCache _cache;
    private readonly AppDbContext _db;

    // One lock guarding the rebuild of this key.
    private static readonly SemaphoreSlim _lock = new SemaphoreSlim(1, 1);

    p
...

// HybridCache (.NET 9) — cache-aside + stampede protection in one call:
var product = await cache.GetOrCreateAsync(
    $"product_{id}",
    async ct => await db.Products.FindAsync(id, ct),
    new HybridCacheEntryOptions { Expiration = TimeSpan.FromMinutes(10) });

using System;
using System.Collections.Generic;

class Program
{
    // 🎯 MINI-CHALLENGE: a tiny cache with a TTL (time-to-live)
    //
    // Store each value together with the DateTime it was added, then
    // EXPIRE it on read if it's older than the TTL.
    //
    // 1. Make a Dictionary that maps a string key to a tuple
    //    (int value, DateTime storedAt).  e.g.
    //       var cache = new Dictionary<string, (int value, DateTime storedAt)>();
    // 2. Choose a TTL, e.g.  var ttl = 
...