Using StackExchange.Redis for Distributed Caching in .NET

A distributed cache gives .NET applications a shared, fast data layer that sits between the application and slower systems such as SQL Server, APIs, and external services. In a single-server application, in-process memory may be enough. As soon as traffic is spread across multiple instances, however, each server can hold a different version of the same data. StackExchange.Redis solves that coordination problem by providing a mature .NET client for Redis.

The approach is especially useful for cloud-hosted systems running on Microsoft Azure, where application instances can scale up and down automatically. A retail platform serving customers in Sydney, Melbourne, Brisbane, and regional areas may have many web nodes behind a load balancer. Shared caching helps those nodes reuse common results, reduce database pressure, and deliver predictable response times during events such as end-of-financial-year sales.

Why Distributed Caching Matters

Caching is based on a simple trade-off: store frequently requested data closer to the application so it can be returned more quickly. Product catalogues, configuration settings, permissions, exchange rates, feature flags, and rendered fragments are common candidates. The cache should contain data that is expensive to calculate or retrieve, yet safe to reproduce when it expires.

An in-memory cache such as IMemoryCache is extremely fast, but its contents belong to one process. If an Azure App Service deployment has six instances, a value written to one instance is invisible to the other five. A user might receive one feature-flag value in Melbourne and another after the next request is routed to Sydney. A distributed cache provides a shared keyspace that every application instance can access.

Redis is an in-memory data store designed for low-latency operations, with optional persistence and useful data structures. It can store strings, hashes, lists, sets, sorted sets, and more. For many ASP.NET Core workloads, the cache abstraction is sufficient, while direct StackExchange.Redis access is valuable when an application needs atomic counters, distributed locks, pub/sub, or specialised Redis commands.

A cache is not a primary source of truth. Database records and business services remain authoritative. If Redis becomes unavailable, the application should have a controlled fallback, graceful degradation, or a clear error path rather than treating cached data as permanent storage.

Connecting .NET Applications to Redis

The StackExchange.Redis NuGet package exposes the ConnectionMultiplexer, the central object used to communicate with Redis. It is designed to be shared and reused, rather than created for every request. Repeatedly opening connections increases network overhead, consumes resources, and can cause avoidable connection storms during periods of high load.

A typical registration in an ASP.NET Core application uses a singleton connection:

builder.Services.AddSingleton<IConnectionMultiplexer>(_ =>
    ConnectionMultiplexer.Connect(
        builder.Configuration.GetConnectionString("Redis")!));

The application can then obtain an IDatabase instance:

public sealed class ProductCache
{
    private readonly IDatabase _database;

    public ProductCache(IConnectionMultiplexer multiplexer)
    {
        _database = multiplexer.GetDatabase();
    }

    public Task<string?> GetAsync(string key) =>
        _database.StringGetAsync(key);

    public Task SetAsync(string key, string value, TimeSpan expiry) =>
        _database.StringSetAsync(key, value, expiry);
}

In production, the connection string should come from a managed configuration system or secret store, not source control. Azure Cache for Redis, private networking, TLS, access keys, and firewall rules all need consideration. Australian organisations may also need to select an Azure Australia East or Australia Southeast region to reduce latency and support data residency requirements under internal governance policies and the Australian Privacy Principles.

ConnectionMultiplexer supports asynchronous operations and multiplexes many requests over a small number of connections. Timeouts, retry policies, abort behaviour, and reconnect settings should be reviewed for the chosen hosting environment. A short timeout may protect the web tier from hanging, while an overly aggressive retry loop can amplify an outage.

Choosing Keys, Values, and Expiry

A cache key should be deterministic, readable, and specific enough to prevent collisions. A useful convention includes the application, environment, entity, identifier, and version:

catalog:prod:product:48192:v2

For tenant-aware systems, include the tenant identifier. For culture-sensitive content, include the locale, such as en-AU. Key naming is operationally important because developers and support teams need to identify related entries during diagnosis. Avoid putting confidential personal information directly into keys, since keys may appear in logs or monitoring tools.

Values are commonly stored as JSON, strings, or binary payloads. JSON is easy to inspect and interoperates well with different services, although serialisation and payload size affect both CPU use and network time. When deciding between System.Text.Json and Newtonsoft.Json, this JSON serializer comparison can help frame the trade-offs around throughput, compatibility, and allocation behaviour.

Set an expiry for nearly every cache entry. A time-to-live prevents obsolete values from remaining indefinitely and limits the impact of forgotten invalidation logic. The right period depends on the data: a currency rate may live for minutes, a product description for hours, and a permission decision for a much shorter period. Randomising expiry slightly can reduce a “thundering herd”, where many entries expire at the same moment.

Cache-aside is the most common pattern. The application reads Redis first, loads the value from the database on a miss, then stores the result:

var cached = await database.StringGetAsync(key);

if (!cached.IsNullOrEmpty)
    return JsonSerializer.Deserialize<Product>(cached!)!;

var product = await repository.GetAsync(productId);
if (product is not null)
{
    var json = JsonSerializer.Serialize(product);
    await database.StringSetAsync(key, json, TimeSpan.FromMinutes(15));
}

return product;

The code should handle a missing database result carefully. Caching a short-lived “not found” marker can protect the database from repeated requests for an invalid identifier, but that marker needs a shorter expiry than a valid record.

Handling Consistency and Failure

The difficult part of caching is usually invalidation. If a product changes, the application can delete its cache key, overwrite it immediately, or allow the old value to expire. Explicit invalidation gives fresher results but must be applied consistently across every update path. A versioned key can reduce collisions during deployments, although old versions still need to expire or be removed.

Distributed locks can prevent several instances from rebuilding the same expensive value at once. Redis supports atomic operations such as StringSet with When.NotExists, which can help implement a short-lived lock. Locks must have an expiry, a unique owner token, and a safe release process. They are not a replacement for transactions in the system of record.

Failures should be expected. Redis may be restarting, unreachable, overloaded, or affected by a network route between an application and its cloud region. A cache read failure should often fall back to the underlying repository, while a write failure may be logged and ignored if caching is an optimisation. This decision depends on the business function: a cached dashboard can degrade gracefully, but a distributed rate limit may require a different policy.

Add metrics for hit rate, miss rate, latency, connection failures, timeouts, memory usage, evictions, and command volume. Logs should include the logical operation and key category without exposing sensitive values. Application Insights, Azure Monitor, and Redis diagnostics can be combined to identify whether slow responses come from serialisation, Redis, the database, or the network.

Applying the Pattern in ASP.NET Core

ASP.NET Core includes IDistributedCache, which offers a provider-neutral API for strings and byte arrays. It is appropriate when an application needs standard operations such as GetAsync, SetAsync, and RemoveAsync without depending on Redis-specific features. The Redis provider can be registered with:

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

This abstraction supports familiar cache-aside services and can simplify testing. Direct IConnectionMultiplexer access remains useful for pipelines, hashes, sorted sets, atomic commands, and pub/sub. Many systems use both: IDistributedCache for ordinary application data and StackExchange.Redis for specialised operations.

Avoid caching entire HTTP responses by default. Large responses increase memory usage, serialisation time, and bandwidth. Cache the underlying data or a carefully selected projection instead. Compression may reduce network traffic, but it adds CPU work and makes operational inspection harder. Measure payload size before choosing a strategy.

Stampede protection is important for popular keys. A basic approach is to serve a slightly stale value while one process refreshes it in the background. Another is to use a lock around regeneration. In either case, cap the refresh duration and ensure a failed refresh does not delete a still-useful value.

Testing should cover cache hits, misses, expiry, invalidation, malformed payloads, Redis unavailability, and concurrent requests. Integration tests using a disposable Redis container are more reliable than mocking every Redis call. Load tests should reflect Australian traffic patterns, including users connecting over variable NBN and mobile networks rather than assuming uniformly low latency.

Comparing Caching Approaches

The right option depends on scale, consistency requirements, operational capability, and the amount of Redis-specific behaviour required. A local cache is often the simplest choice for immutable reference data, while a shared Redis cache is a stronger fit for session state and values accessed by several application instances.

For an Australian SaaS product, a Redis deployment in the same Azure region as its application instances can reduce round-trip time and keep traffic within an appropriate hosting boundary. A service operating across Sydney and Melbourne should define whether Redis is regional, replicated, or accessed centrally. Cross-region designs may improve resilience but add latency and raise questions about replication lag and data handling.

Capacity planning matters as much as code quality. Estimate key count, average value size, expiry patterns, peak requests per second, and memory overhead. Configure eviction policies deliberately, because evicting a frequently used key can cause a sudden database surge. Separate high-value cached data from temporary counters where practical, and monitor usage before a seasonal spike such as Boxing Day sales or an end-of-financial-year promotion.

Operating a Reliable Redis Cache

Security begins with private connectivity, TLS, strong credentials, least-privilege access, and careful separation between development, staging, and production. Never place customer records, payment details, or access tokens in Redis without a clear security design. Cache only the fields required by the consuming operation, and apply retention rules to temporary data.

Deployments should account for schema changes in cached payloads. Adding optional JSON properties is generally safer than renaming or removing required ones. Versioned keys, tolerant deserialisation, and a deliberate cache flush plan can prevent a new application version from failing on values created by an older release.

A healthy implementation treats caching as an observable subsystem rather than invisible plumbing. Track hit ratio by key family, monitor p95 and p99 command latency, alert on rising timeouts, and review evictions alongside application errors. With sensible expiry, explicit invalidation, resilient connection management, and measurements from real workloads, StackExchange.Redis can provide a dependable shared cache for modern .NET applications.