Choosing the Right Cache for ASP.NET Core Session Data

Session state can look simple in a local ASP.NET Core application. A visitor signs in, adds an item to a basket, or completes a multi-step form, and the application remembers the relevant values between requests. The design becomes more important when the application runs across several servers, containers, or availability zones.

The main choice is usually between IMemoryCache and IDistributedCache. Both can store short-lived data, yet they offer very different guarantees around availability, consistency, scaling, and operational complexity. The best option depends on whether session data must survive requests reaching different application instances.

For an Australian business, deployment location can also influence the decision. An application hosted in an Azure Australia East or Australia Southeast region may need predictable latency, data residency controls, and a failure plan that works during busy periods such as end-of-financial-year processing or major retail campaigns.

Using IMemoryCache vs IDistributedCache for Session Data in ASP.NET Core requires a distinction between a fast local cache and a shared session store. Understanding that distinction prevents a common production problem: an application that works perfectly on a developer laptop but loses state after load balancing or a container restart.

How the two cache abstractions differ

IMemoryCache stores values in the memory allocated to the current .NET process. It is straightforward to register with dependency injection and is very fast because reads and writes avoid serialisation and network communication. It is well suited to data that can be recreated, such as configuration lookups, product metadata, or a calculated response used by one application instance.

Its scope is also its limitation. When a load balancer sends the next request to another instance, that instance has a different memory cache. A restart, deployment, scale-out event, or process crash clears the entries. Even a single virtual machine can have several worker processes, each with its own cache.

IDistributedCache defines a common API for a shared cache provider. ASP.NET Core can use Redis, SQL Server, PostgreSQL, NCache, or a custom implementation behind the same abstraction. The application pays a small performance cost for the shared store, but every web node can retrieve the same session value.

A key detail is that AddDistributedMemoryCache() does not create a distributed cache. It registers an in-memory implementation of IDistributedCache, useful for development and simple single-server deployments. The interface name does not change the storage behaviour.

Why session data needs shared storage

ASP.NET Core session middleware stores a session identifier in a cookie and keeps the associated values in an IDistributedCache implementation. This design allows multiple application instances to handle requests for the same visitor, provided they share the same backing store and configuration.

An IMemoryCache entry can support session-like behaviour in a small internal tool, but it does not provide reliable cross-instance session state. Sticky sessions can keep a visitor attached to one server, yet they reduce routing flexibility and can create uneven load. They also fail to solve data loss after that server is recycled.

Shared storage is especially relevant for applications hosted in Sydney and Melbourne regions with multiple instances behind Azure App Service, a reverse proxy, or Kubernetes. A user might submit a form through one pod and retrieve the next step through another. If the state exists only in local memory, the second request may appear to start a new session.

Session should still contain only modest, temporary data. Store an identifier, selected preferences, or a small workflow state rather than a complete customer record. Large values increase serialisation time, network traffic, and pressure on the backing service.

Selecting a provider for a distributed cache

Redis is a common choice when low-latency session access, expiry policies, and high throughput matter. Azure Cache for Redis can provide a managed option, while self-hosted Redis may suit teams with existing platform expertise. A production design should account for connection resilience, TLS, access keys or managed identity, capacity limits, and what happens if Redis becomes unavailable.

SQL Server and PostgreSQL providers can be practical where the organisation already operates a relational database and wants fewer infrastructure components. They may be easier to govern in a heavily regulated environment, but session traffic can compete with business queries. Database-backed caching also needs suitable indexes, cleanup behaviour, connection pooling, and monitoring.

Australian organisations often assess whether customer information remains within an Australian cloud region. That requirement may arise from contractual obligations, internal policy, or the Privacy Act context rather than from a single universal rule. Confirm the provider’s region, replication model, support access, backup location, and cross-border transfer terms before placing personal information in a cache.

A cache provider is not automatically a durable system of record. Expiry, eviction, maintenance, and failover can remove data. If losing a session would cause financial or compliance harm, persist the important business transaction in a database and use the cache only to improve continuity and speed.

Configuring session state safely

A typical shared-session setup registers a concrete distributed provider, then adds session middleware:

builder.Services.AddStackExchangeRedisCache(options =>
{
    options.Configuration = builder.Configuration.GetConnectionString("Redis");
    options.InstanceName = "orders:";
});

builder.Services.AddSession(options =>
{
    options.IdleTimeout = TimeSpan.FromMinutes(20);
    options.Cookie.HttpOnly = true;
    options.Cookie.IsEssential = true;
    options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
});

var app = builder.Build();

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseSession();
app.MapControllers();

Middleware order matters. Session must run after components that establish the request context it relies on and before endpoints that read or write HttpContext.Session. If authentication, consent, or custom middleware depends on session values, place those components deliberately and test the complete pipeline.

Session cookies should be protected with HTTPS, HttpOnly, an appropriate SameSite policy, and a carefully considered domain and path. Avoid putting secrets, payment details, or unnecessary personal information into session. The cookie generally carries an identifier, while the value remains in the server-side store.

Use consistent data protection keys across application instances when cookie authentication or other protected state is shared. Without a common key ring, one node may be unable to decrypt a cookie issued by another node. This can look like a cache or session fault even though the underlying problem is key management.

Handling expiration, concurrency, and failure

Every session value needs a useful lifetime. An idle timeout helps remove abandoned shopping baskets and incomplete forms, while an absolute business deadline can prevent old workflow data from being accepted. Align cache expiry with the user journey instead of choosing a long duration simply to avoid cache misses.

Concurrent requests can update the same session. Multiple browser tabs, mobile retries, AJAX calls, and slow connections may read an old value and then overwrite a newer one. Keep updates small and deliberate. For critical counters or reservations, use a transactional database operation or a provider-specific atomic command rather than relying on session as a concurrency mechanism.

Treat cache failure as an expected operational condition. Decide whether the application should show a recoverable error, begin a fresh session, or temporarily disable a workflow. A retry policy that blindly repeats every cache call can increase an outage. Use bounded timeouts, circuit breaking where appropriate, and clear user-facing behaviour.

Observability should cover cache latency, connection failures, misses, evictions, session creation, and unusually large payloads. Correlation IDs make it easier to connect an individual request with a provider error; a practical reference for extending this approach is a distributed tracing guide focused on OpenTelemetry in .NET.

Testing the design before release

A local test using AddDistributedMemoryCache() can confirm controller and middleware behaviour, but it cannot prove that the application works across nodes. Run integration tests against the same provider family used in production, including expiry, reconnect, and serialisation scenarios.

Scale tests should send a single browser session through multiple instances. Verify that a request can write state on one node and read it on another, then repeat the test during deployment, instance replacement, and provider failover. For an Australian service, include latency tests from likely users in Sydney, Melbourne, Brisbane, Perth, and regional areas where network conditions may differ.

The checks below help separate an acceptable design from a fragile one.

Architecture checks

• Confirm every production instance uses the same distributed-cache endpoint and namespace.
• Verify session data remains available when an instance is restarted or drained.
• Check that cache and database regions match the organisation’s residency requirements.
• Keep sensitive or durable business records outside session storage.

Operational checks

• Measure hit rate, payload size, latency, timeouts, and eviction activity.
• Test Redis or database failover with a documented recovery response.
• Set alerts for connection failures before users report lost baskets or forms.
• Review session expiry and cookie settings during security testing.

The choice is therefore a workload decision rather than a preference for one interface. Use IMemoryCache for disposable, process-local data where a miss is harmless. Use IDistributedCache with a real shared provider when users can move between instances or when session continuity matters.

For a single-server prototype, local memory may be sufficient. For a customer-facing application expected to scale across Australian cloud infrastructure, a managed distributed cache generally offers a more predictable foundation. Keep session small, protect it carefully, monitor its dependencies, and ensure the underlying business process can recover when temporary state disappears.