IMemoryCache in ASP.NET Core: Production Patterns, Pitfalls, and When to Avoid It

Introduction: The Double-Edged Sword of In-Memory Caching

I once debugged a production outage where an ASP.NET Core API crashed like every 4 hours.. The culprit? An unbounded IMemoryCache storing full Entity Framework entities with basically no size limit. The cache just grew and grew until the pod hit its memory ceiling and, well, OOM-killed itself.

IMemoryCache is incredibly powerful for reducing database load, but it’s not exactly a silver bullet. Used correctly it can cut response times from 400ms to under 50ms, but used poorly? it introduces subtle bugs, memory pressure, and inconsistent data. This guide covers what the official docs don’t really tell you: how to safely implement caching in high-traffic .NET applications.

Safe Setup: Beyond AddMemoryCache()

Registering the service is trivial, but configuring it properly is where most teams honestly fail. Always set a size limit and default expiration to prevent runaway memory usage:

              builder.Services.AddMemoryCache(options =>
{
    // CRITICAL: Prevent unbounded growth
    options.SizeLimit = 1024; // Arbitrary units, not bytes

    // Set sensible defaults so forgotten entries don't linger
    options.ExpirationScanFrequency = TimeSpan.FromMinutes(2);
});

            

Why SizeLimit Matters: Without it, a single hot endpoint can just consume all available memory. The SizeLimit is in arbitrary units, you define what "1 unit" means per cached item (see next section).

Production-Ready Caching Pattern

The basic GetOrCreateAsync example in docs omits some critical safeguards. Here’s a pattern I actually use in production that handles cancellation, normalizes keys, and assigns meaningful sizes:

              public async Task<List<ProductDto>> GetProductsAsync(
    CancellationToken cancellationToken = default)
{
    const string cacheKey = "products:all:v2"; // Versioned keys!

    return await _cache.GetOrCreateAsync(
        cacheKey,
        async entry =>
        {
            // Assign size based on expected object graph
            entry.Size = 10;

            // Use sliding + absolute expiration combo
            entry.SlidingExpiration = TimeSpan.FromMinutes(5);
            entry.AbsoluteExpirationRelativeToNow =
                TimeSpan.FromHours(1);

            try
            {
                var products = await _repository
                    .GetProductsAsync(cancellationToken);

                // Cache DTOs, NEVER entities
                return products.Select(p => new ProductDto(
                    p.Id, p.Name, p.Price)).ToList();
            }
            catch (OperationCanceledException)
            {
                // Don't cache canceled operations
                entry.Abort();
                throw;
            }
        });
}

            

Expiration Strategies: Trade-Offs Explained

Choosing between sliding and absolute expiration isn’t just academic, it directly impacts user experience and system stability:

My Rule of Thumb: Use sliding expiration for user-facing data (so active users always get fresh results) and absolute expiration for background or reference data. Never rely solely on sliding expiration for critical business data, users who step away for lunch shouldn’t trigger a massive cache miss storm when they return.

Realistic Performance Expectations

Benchmarks vary wildly based on data size, serialization, and hardware.. Here are results from a recent production migration (Azure B2s VM, SQL Server):

Critical Caveat: The first request after deployment or cache eviction will be slow. Always pre-warm critical caches during startup or use a background service to populate them asynchronously, otherwise you'll feel the pain.

When NOT to Use IMemoryCache

IMemoryCache is local to each process. You should probably avoid it when:

• ●

  Multiple Instances: K8s pods or cloud scale-out scenarios basically require distributed caching (like Redis).

• ●

  Large Data Sets: Caching >100MB of data risks OOM kills. Just use pagination or external storage.

• ●

  Shared State: If multiple services need consistent cached data, IMemoryCache will diverge, guaranteed.

• ●

  Long-Lived Data: Items needed beyond app restarts should really use persistent caching.

"IMemoryCache solves latency problems, not consistency problems.. If data accuracy matters more than speed, just skip the cache."

Monitoring & Debugging Cache Health

You can’t manage what you don’t measure. You really need to implement these metrics in production:

• ●

  Hit/Miss Ratio: Target >80% for hot paths, low ratios usually indicate wrong TTLs or key design.

• ●

  Memory Pressure Events: Log when cache evicts items due to size limits.

• ●

  Eviction Reasons: Track whether items expire naturally or are force-evicted.

• ●

  Serialization Time: High CPU during cache writes suggests you should optimize DTOs.

Use IMemoryCacheStatistics (available in .NET 8+) or custom middleware to expose these metrics to Prometheus/Grafana.

Frequently Asked Questions

Conclusion

Next steps: Read our guides on [Redis Distributed Caching Patterns] and [ASP.NET Core Performance Profiling] to complete your caching strategy, you got this.