Redis and Hybrid Caching in .NET: Performance Without Losing Correctness

History and context

Why caching exists

Caching trades freshness complexity for less repeated work. It is most useful when data is expensive to obtain, read frequently and safe to serve according to a clear staleness policy.

Cache-aside architecture

Cache-aside in code

var cached = await cache.GetStringAsync(key, cancellationToken);

if (cached is not null)
    return JsonSerializer.Deserialize<ProductDto>(cached);

var product = await repository.GetAsync(productId, cancellationToken);

await cache.SetStringAsync(
    key,
    JsonSerializer.Serialize(product),
    new DistributedCacheEntryOptions
    {
        AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10)
    },
    cancellationToken);

return product;

HybridCache for two-level caching

ASP.NET Core's HybridCache library is designed to combine local and distributed caching while helping with common cache concerns such as stampede protection.

var product = await hybridCache.GetOrCreateAsync(
    $"product:{productId}",
    async token => await repository.GetAsync(productId, token),
    cancellationToken: cancellationToken);

Invalidation is the architecture

The most important cache question is not how fast Redis is. It is what makes a cached value stop being trusted.

• TTL expiration
• Explicit eviction after writes
• Versioned keys
• Event-driven invalidation
• Change-data-capture approaches for selected workloads

Design for Redis failure

A cache should not silently become the only copy of critical business data. For ordinary cache-aside scenarios, application behaviour should remain correct if the cache is unavailable, while protecting the database from a sudden thundering herd.

What not to cache casually

• Unfinalised financial calculations with unclear invalidation
• Authorisation decisions without a strong revocation policy
• Inventory values where stale data can oversell
• Large objects with low reuse

Business value and practical considerations

References