Three servers, three memories, three different answers to the same question.

The previous lesson's caching worked perfectly — in testing, on your one laptop, running one instance of the app. Then you deploy to production behind a load balancer, running three instances for reliability and capacity. A user updates their profile picture. The request happens to land on instance A, which updates the database and caches the new picture URL in its own IMemoryCache. The user refreshes the page. This request lands on instance B — which has never heard of that update. Its own, completely separate IMemoryCache still has the old picture cached, or nothing cached at all. The user sees their old photo, or a flash of inconsistent behavior, depending on which instance happens to answer each request.

This isn't a bug in your caching code. It's the fundamental nature of IMemoryCache: it lives inside one process. The moment you have more than one process, you have more than one cache, and they don't talk to each other.

In this lesson, you'll learn exactly why in-process caching breaks down at multiple instances, what IDistributedCache is, why Redis is the typical backing store behind it, and the cache-aside pattern that ties it all together.

What Is It?

The Simple Explanation

Distributed caching means moving the cache out of your app's process and into a separate, shared service that every instance of your app connects to over the network. Instead of each instance keeping its own private notebook, every instance now writes to and reads from the same shared notebook.

The Technical Definition

IDistributedCache is ASP.NET Core's abstraction over a shared, out-of-process cache — an interface with the same basic shape as IMemoryCache (GetAsync, SetAsync, RemoveAsync), but backed by an external store reachable over the network rather than by local process memory. Because it's an abstraction, your application code doesn't need to know or care which specific technology is behind it — you write against IDistributedCache once, and the concrete backing store is a matter of configuration.

Why Does It Exist?

The Problem — IMemoryCache Genuinely Cannot Do This

This isn't a matter of configuring IMemoryCache differently or being more careful — it's a hard architectural limit. Each instance of your app is a separate operating system process, with its own separate block of memory. IMemoryCache is, under the hood, essentially a dictionary sitting inside that memory. There is no built-in channel for instance A's dictionary to notify instance B's dictionary that an entry changed, because they don't share any memory at all — they're on entirely different machines (or at minimum, entirely different processes), often behind a load balancer that routes each incoming request to whichever instance it decides to, with no guarantee two requests from the same user even land on the same one.

This produces two distinct, real problems in a multi-instance deployment:

• Inconsistent reads — the same request, hitting different instances, can get different cached answers, because one instance's cache reflects a write the others don't know about.
• Redundant warm-up — the very first request for a given piece of data on each instance is a cache miss, even if every other instance already has it cached. Ten instances means the expensive underlying work potentially runs ten separate times, once per instance, instead of once total.

The Solution — One Shared Cache, Reached Over the Network

If the problem is "every instance has its own cache," the fix is structural: stop keeping the cache inside each instance's own memory, and instead put it somewhere all instances can reach — a separate service, reachable over the network, that every instance of your app talks to identically. Now a write from instance A is immediately visible to instances B and C on their very next read, because there's only one cache, not three.

Big Picture

WITHOUT DISTRIBUTED CACHING — 3 ISLANDS

  Instance A            Instance B            Instance C
 ┌──────────┐          ┌──────────┐          ┌──────────┐
 │IMemoryCache│         │IMemoryCache│        │IMemoryCache│
 │  (empty)  │          │ {pic: X} │          │  (empty)  │
 └──────────┘          └──────────┘          └──────────┘
      ↑                      ↑                     ↑
   Request 1            Request 2 (wrote X)    Request 3
  (different answers, depending purely on which instance answers)


WITH DISTRIBUTED CACHING — 1 SHARED CACHE

  Instance A            Instance B            Instance C
      \                     |                     /
       \                    |                    /
        ╲                   ↓                   ╱
              ┌─────────────────────────┐
              │   Shared Cache (Redis)   │
              │        {pic: X}          │
              └─────────────────────────┘
   Every instance reads and writes the SAME data — consistent, no redundant warm-up

How It Works

byte[]? cached = await cache.GetAsync(cacheKey);

await cache.SetAsync(cacheKey, serialized, options);
return result;

Simple Example

Registering Redis as the backing store for IDistributedCache is almost entirely configuration — your application code depends only on the abstraction:

// Program.cs
builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("Redis");
    options.InstanceName = "MyApp:";
});

And a cache-aside implementation, using IDistributedCache exactly as designed:

using System.Text.Json;

public class ProductService(AppDbContext db, IDistributedCache cache)
{
    public async Task<Product?> GetProductAsync(int productId)
    {
        var cacheKey = $"product:{productId}";

        // 1. Check the shared cache
        var cachedBytes = await cache.GetAsync(cacheKey);
        if (cachedBytes is not null)
        {
            return JsonSerializer.Deserialize<Product>(cachedBytes);
        }

        // 2. Miss — go to the real source
        var product = await db.Products.FindAsync(productId);
        if (product is null) return null;

        // 3. Populate the cache before returning
        var options = new DistributedCacheEntryOptions
        {
            AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5)
        };
        await cache.SetAsync(cacheKey, JsonSerializer.SerializeToUtf8Bytes(product), options);

        return product;
    }
}

Notice this reads almost identically to the previous lesson's IMemoryCache example — same shape, same pattern. The difference that matters is entirely underneath: this cache entry is now visible to every instance of the app that shares the same Redis connection, not just the one that happened to write it.

Real-World Example

Consider a shopping cart summary shown on every page of an e-commerce site — item count and total, computed from cart line items. Behind a load balancer running four instances, a user's requests can land on any of them as they browse. Without a shared cache, whichever instance last computed the total for this user is the only one that has it; the other three would each redundantly recompute it on their own first encounter with that user's session, and none of them would see a cart update made via a different instance without recomputing.

With IDistributedCache backed by Redis, one instance computes the cart summary once, caches it under a key like $"cart-summary:{userId}", and the moment the user adds an item — regardless of which instance handles that write — the code explicitly invalidates (removes) that same cache key. Every instance's very next read for that user is a clean cache miss that recomputes the correct, current total; every read before the next write is a fast, consistent hit, identical no matter which instance answers it.

Analogy

Under the Hood

Common Confusion

"Just switch from IMemoryCache to IDistributedCache and everything works the same" — mostly, but not free

The API shapes are deliberately similar, and for many use cases swapping the implementation genuinely is close to a drop-in change. But it isn't free: IDistributedCache requires you to serialize and deserialize your data yourself (it only stores raw byte[]), and every operation now costs a real network round-trip instead of an in-process lookup. For a value read millions of times a second inside a single request's processing, that added latency and serialization cost genuinely matters — it's why some systems use both: a fast local IMemoryCache as a first-level cache, backed by a shared distributed cache as the second level.

"Distributed caching solves invalidation" — it doesn't, it just changes where it happens

Moving to a shared cache doesn't make the previous lesson's hard problem — knowing when a cached value is stale — go away. It actually adds a wrinkle: now every instance needs to agree on when and how to invalidate a shared entry, since a write from any one of them affects what every other instance sees next. The cache-aside pattern's explicit invalidation step is exactly how you handle this — but you still have to write it correctly.

Common Mistakes

Mistake 1 — Assuming IMemoryCache is "good enough" once you scale out

Keeping IMemoryCache in a multi-instance deployment and hoping the inconsistency "won't matter much" — it will surface, unpredictably, exactly when traffic is highest and load-balancing spreads requests widest.

Once you run more than one instance, treat shared, potentially-inconsistent state as a real design question, not an edge case — reach for IDistributedCache for anything that must be consistent across instances.

Mistake 2 — Forgetting the cache-aside pattern's invalidation step

Populating the cache on read but never removing or updating the entry when the underlying data changes on write — the shared cache becomes a single, consistently wrong answer served to every instance, which is arguably worse than the per-instance inconsistency it replaced.

Every code path that writes to the real data source should also invalidate (or update) the corresponding cache entry, as part of the same operation.

Mistake 3 — Treating the distributed cache as durable storage

Relying on Redis (or any distributed cache) as the only place a piece of data lives — caches are typically configured for performance, not durability, and can lose data on restart or eviction under memory pressure.

The real source of truth stays the database (or other durable store); the cache-aside pattern's whole design assumes the cache can be safely emptied at any time and rebuilt from the real source.

When Should I Use It?

• Use IDistributedCache the moment your app runs as more than one instance and cached data needs to be consistent across those instances.
• Prefer it for data shared across users or sessions in a load-balanced deployment — catalog data, configuration, computed aggregates.
• Stick with plain IMemoryCache for a genuinely single-instance app, or for extremely hot, per-request-cheap lookups where a network round-trip would erase the benefit entirely (sometimes layered as a fast local cache in front of the distributed one).
• Either way, the underlying hard problem doesn't change: only cache what's read far more than it's written, and always have a real invalidation plan.

Mental Model

Key Takeaway

Check Your Understanding

You've seen why IMemoryCache breaks down across multiple instances, and how IDistributedCache and cache-aside fix it. Let's confirm the reasoning.

You now understand why in-process caching breaks down at scale, and how IDistributedCache with the cache-aside pattern keeps every instance of your app looking at the same, consistent data.

dotnetmadeeasy.com — Learn C# and .NET, the right way.