The fastest way to answer a question is to not ask it a second time.

Your homepage shows a "top 10 products" list. Computing it means querying every order in the last 30 days, grouping by product, summing quantities, and sorting the result — a query that takes 400ms and hits the database hard. That would be fine if one person loaded the homepage once. But ten thousand people load it every minute, and the underlying data — what's popular this month — barely changes between one request and the next. You are doing the exact same expensive work, over and over, to produce the exact same answer, thousands of times an hour.

Caching exists to fix exactly this: do the expensive work once, remember the answer, and hand out the remembered answer to everyone who asks next — until it's no longer trustworthy.

In this lesson, you'll learn IMemoryCache (in-process caching), the newer output caching middleware, why [ResponseCache] is a different and more limited tool than it sounds, and — the genuinely hard part — how to think about cache invalidation without shipping stale data to your users.

What Is It?

The Simple Explanation

Caching means storing the result of expensive work somewhere fast, and checking that storage before redoing the work. If the answer is already sitting there and still trustworthy, you skip the expensive part entirely and hand back the stored copy.

This lesson is about caching inside one running instance of your ASP.NET Core application — memory that lives inside your app's process, on the one machine that process happens to be running on right now. That scope matters, and the next lesson exists specifically because of it.

The Technical Definition

ASP.NET Core gives you two genuinely different in-process caching tools, aimed at two different layers of your application:

Both live and die inside the memory of a single running instance of your app. Neither one is shared with any other copy of your app that might be running elsewhere — that distinction is the entire subject of the next lesson.

Why Does It Exist?

The Problem — Doing Expensive Work Nobody Needs Fresh

Some data is expensive to produce: a complex aggregate query, a call to a slow third-party API, a computation that takes real CPU time. And some of that data is read far more often than it actually changes — a product catalog page, a list of countries for a dropdown, an exchange rate that updates once an hour, a "top products" widget recomputed nightly by a batch job but read thousands of times a minute. Recomputing or refetching that answer on every single request wastes CPU, database load, and time — and the honest truth is that most of those requests would have gotten the exact same answer as the one before it.

The Solution — Remember the Answer, For a While

Caching trades a small amount of memory for a large amount of avoided work. Compute or fetch the answer once, store it, and serve the stored copy to every request that arrives while it's still considered fresh. When it's no longer fresh — because it expired, or because you know the underlying data changed — you let the next request pay the real cost again, get the new answer, and cache that instead.

Big Picture

WITHOUT CACHING

Request 1 → run expensive query (400ms) → return result
Request 2 → run expensive query (400ms) → return result   (same result!)
Request 3 → run expensive query (400ms) → return result   (same result!)
    ↓
Database hammered with identical, avoidable work


WITH CACHING

Request 1 → cache empty → run expensive query (400ms) → store result → return result
Request 2 → cache HIT → return stored result (< 1ms)
Request 3 → cache HIT → return stored result (< 1ms)
    ↓ (after expiration, or explicit invalidation)
Request N → cache MISS → run query again → store fresh result → return result

The performance win is real and often dramatic. But notice the trade you just made: for a window of time, some requests are being served an answer that is not a live, real-time query against the true underlying data — it's a snapshot from whenever it was cached. Managing that gap between "cached" and "true right now" is what the rest of this lesson is really about.

How It Works

builder.Services.AddMemoryCache();

if (!cache.TryGetValue(cacheKey, out Product? product))
{
    // MISS — fall through to step 3
}

product = await dbContext.Products.FindAsync(productId);
cache.Set(cacheKey, product, TimeSpan.FromMinutes(5));

Simple Example

The classic IMemoryCache pattern — often written with GetOrCreateAsync, which combines the "check, then populate" steps into one call:

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

        return await cache.GetOrCreateAsync(cacheKey, async entry =>
        {
            entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5);
            return await db.Products.FindAsync(productId);
        });
    }
}

Line by line: GetOrCreateAsync checks whether cacheKey already has a value. If it does, that value is returned immediately — the lambda never runs. If it doesn't, the lambda runs, sets an expiration on the new entry, and its return value both gets stored in the cache and returned to the caller. Every subsequent call with the same productId, within five minutes, skips the database entirely.

Real-World Example

Output caching goes a level higher: instead of caching one piece of data inside your method, it caches the entire rendered HTTP response for a route, so a repeat request never even reaches your endpoint's code:

// Program.cs
builder.Services.AddOutputCache(options =>
{
    options.AddPolicy("ProductCatalog", policy =>
        policy.Expire(TimeSpan.FromMinutes(2)).Tag("catalog"));
});

var app = builder.Build();
app.UseOutputCache(); // must come after routing, before endpoints run

app.MapGet("/api/products", async (AppDbContext db) =>
{
    // On a cache HIT, this handler never executes at all.
    return await db.Products.OrderBy(p => p.Name).ToListAsync();
})
.CacheOutput("ProductCatalog");

The first request runs the handler, queries the database, and caches the full serialized response for two minutes, tagged "catalog". Every request in that window — from any client — gets the cached response served directly by the output caching middleware, with zero of your endpoint code, and zero database round-trips, running again. The Tag matters: it gives you a handle to invalidate this cached response explicitly (via IOutputCacheStore.EvictByTagAsync("catalog", ...)) the moment a product actually changes, rather than waiting out the full two minutes.

Analogy

Under the Hood

Common Confusion

"There are only two hard problems in computer science"

You'll hear a version of an old programmer joke, usually attributed to Phil Karlton: "There are only two hard things in computer science: cache invalidation and naming things." It's funny because it's true — cache invalidation is a genuinely, nontrivially hard problem, not a beginner-level afterthought. The hard part isn't storing the value; it's knowing, correctly and reliably, the exact moment a cached value stops being an accurate reflection of reality. Get it wrong and you don't get a crash — you get a system that runs perfectly and quietly returns wrong answers.

"[ResponseCache] caches on the server" — usually not

As covered above, [ResponseCache] primarily emits caching headers. Its Location = ResponseCacheLocation.Any option can, in specific hosting configurations, enable server-side caching via a separate response caching middleware — but that's the exception, not what most people mean when they reach for the attribute. If your goal is genuine server-side caching of full responses, output caching middleware is the direct, modern tool for that job.

Common Mistakes

Mistake 1 — Caching with no expiration at all

cache.Set(key, value) with no expiration means the entry lives until it's explicitly removed or evicted under memory pressure — an easy way to silently serve data that's hours or days stale.

Always set an explicit expiration appropriate to how quickly the underlying data can realistically change — even a short one is a safety net.

Mistake 2 — Caching data that changes per-request but keying it too broadly

Caching a "current user's cart total" under a single shared key that doesn't include the user's ID — every user ends up seeing whichever user's total got cached first. This is a correctness bug, not just a staleness one.

Build cache keys from everything that makes the value unique: $"cart-total:{userId}", not just "cart-total".

Mistake 3 — Caching data that changes on almost every write

Wrapping a value in a cache when the write-to-read ratio is roughly 1:1 — you pay all the complexity of managing cache invalidation and get almost none of the performance benefit, because the cache is invalidated about as often as it would have been recomputed anyway.

Reserve caching for data that's read far more often than it's written — that's where the trade genuinely pays off.

When Should I Use It?

Caching genuinely helps when:

• The underlying data is expensive to compute or fetch — a heavy query, an external API call, real CPU work.
• The data is read far more often than it changes — a product catalog, reference/lookup data, a computed report refreshed periodically.
• Being slightly stale for a bounded window is genuinely acceptable for the use case.

Caching is the wrong tool — or a dangerous one — when:

• The data changes about as often as it's read — invalidation complexity outweighs the savings.
• Staleness has real consequences — an account balance, remaining inventory at checkout, anything tied directly to money or safety.
• The data is cheap to compute already — caching adds complexity and a new class of bugs for no real performance win.

Mental Model

Key Takeaway

Check Your Understanding

You've seen how in-process caching works and why invalidation is the real challenge. Let's check your reasoning.

You now understand in-process caching with IMemoryCache and output caching — and why cache invalidation is the part that actually takes engineering judgment. Next: what happens once your app runs as more than one instance.

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