IMemoryCache for Single-Instance Caching
IMemoryCache stores data in the memory of the process running the ASP.NET Core app itself, registered via builder.Services.AddMemoryCache() and injected wherever needed. It's extremely fast because there's no network hop involved, but the cached data lives and dies with that one process — a second instance behind a load balancer has its own separate, unsynchronized cache, and a restart or deployment wipes it entirely. The GetOrCreateAsync extension method is the idiomatic pattern: it looks up a key, and if missing, executes a factory delegate to compute the value, sets it with a MemoryCacheEntryOptions (absolute or sliding expiration), and stores it in one atomic-feeling call.
Cricket analogy: IMemoryCache is like a single fielder's personal mental note of where the ball last landed — instantly useful to that one fielder, but useless to teammates at the other end of the ground who have no idea about it, and it's forgotten the moment that fielder leaves the field.
Expiration policy is where IMemoryCache is most often misused: absolute expiration guarantees an entry is evicted after a fixed duration regardless of access pattern, which is right for data that genuinely goes stale on a schedule (like a daily exchange rate), while sliding expiration resets the timer on every access, which suits frequently-hit hot data you want to keep warm as long as it's actively used but evict once it goes cold. Combining both — an absolute expiration ceiling alongside a sliding window — prevents a hot key from being cached forever, which matters because IMemoryCache has no built-in memory-pressure eviction guarantee unless you also configure SizeLimit and assign a Size to each entry.
Cricket analogy: Absolute expiration is like a strict drinks-break schedule called at a fixed time regardless of how the play is going; sliding expiration is like a bowler's spell continuing only as long as they keep taking wickets, reset with every success but pulled the moment they go cold.
IDistributedCache and Cache-Aside
IDistributedCache is the interface for a cache backed by an external store — most commonly Redis via AddStackExchangeRedisCache(), or SQL Server via AddDistributedSqlServerCache() — shared across every instance of the app, which is essential once you're running behind a load balancer with multiple replicas that all need to see the same cached value. Unlike IMemoryCache, IDistributedCache only stores byte arrays or strings, so complex objects need explicit serialization, typically with System.Text.Json, before calling SetStringAsync and JSON-deserializing after GetStringAsync. The near-universal pattern for using either cache is cache-aside: check the cache first, and on a miss, query the database, populate the cache, and return the result — with careful attention to invalidating or updating the cache entry whenever the underlying data changes via a write path.
Cricket analogy: IDistributedCache is like the official scoreboard shared by every screen around the stadium and every broadcaster's feed simultaneously — unlike one fielder's private mental note, this single shared source keeps every viewer, umpire, and commentator in sync regardless of which stand they're sitting in.
// Program.cs
builder.Services.AddStackExchangeRedisCache(options =>
{
options.Configuration = builder.Configuration.GetConnectionString("Redis");
options.InstanceName = "skillveris:";
});
public class CourseCatalogService
{
private readonly IDistributedCache _cache;
private readonly ICourseRepository _repo;
public CourseCatalogService(IDistributedCache cache, ICourseRepository repo)
{
_cache = cache;
_repo = repo;
}
public async Task<IReadOnlyList<Course>> GetActiveCoursesAsync(CancellationToken ct)
{
const string key = "courses:active";
var cached = await _cache.GetStringAsync(key, ct);
if (cached is not null)
return JsonSerializer.Deserialize<List<Course>>(cached)!;
var courses = await _repo.GetActiveCoursesAsync(ct);
await _cache.SetStringAsync(
key,
JsonSerializer.Serialize(courses),
new DistributedCacheEntryOptions
{
AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10),
SlidingExpiration = TimeSpan.FromMinutes(3),
},
ct);
return courses;
}
public Task InvalidateActiveCoursesAsync(CancellationToken ct) =>
_cache.RemoveAsync("courses:active", ct);
}
HybridCache, introduced as a first-class abstraction in .NET 9, unifies IMemoryCache and IDistributedCache behind one API with built-in stampede protection — concurrent requests for the same missing key coalesce into a single factory call instead of each triggering a redundant database hit.
Forgetting to call RemoveAsync (or otherwise invalidating the cache key) on the write path is the most common caching bug: a course's title gets updated in the database but the stale cached list keeps serving the old value for the remainder of its expiration window, silently confusing users.
- IMemoryCache lives in the app process's own memory — fastest option, but not shared across load-balanced instances.
- GetOrCreateAsync is the idiomatic IMemoryCache pattern: look up, compute on miss, store with expiration options.
- Absolute expiration evicts on a fixed schedule; sliding expiration resets on each access and suits frequently-hit hot data.
- IDistributedCache (Redis, SQL Server) is shared across every app instance, essential behind a load balancer.
- IDistributedCache only stores strings/bytes, so complex objects need explicit JSON serialization.
- Cache-aside is the standard pattern: check cache, query database on miss, populate cache, return result.
- Always invalidate or update cache entries on the write path to avoid serving stale data after an update.
Practice what you learned
1. What is the main limitation of IMemoryCache in a load-balanced ASP.NET Core deployment?
2. What is the difference between absolute and sliding expiration?
3. What data types can be stored directly in IDistributedCache?
4. What is the cache-aside pattern?
5. What is the most common caching bug described for the write path?
Was this page helpful?
You May Also Like
Background Services with IHostedService
How to run long-lived and scheduled background work in ASP.NET Core using IHostedService and the BackgroundService base class.
Entity Framework Core Integration
How to wire Entity Framework Core into an ASP.NET Core application, from DbContext registration to migrations and query patterns.
Service Lifetimes: Singleton, Scoped, Transient
How ASP.NET Core's built-in dependency injection container manages object lifetime through Singleton, Scoped, and Transient registrations.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics