Does HybridCache use distributedLock ?

[John0King]

I read the DefaultHybridCache source code , I haven't found how it handles the L2 cache expiration issue across multiple instances.

[MentalOfCrow]

No. The built-in stampede lock in DefaultHybridCache is process-local, not distributed across application instances.

The implementation keeps in-flight work in an instance field:

private readonly ConcurrentDictionary<StampedeKey, StampedeState> _currentOperations = new();

and callers in that same process join the matching StampedeState:

https://github.com/dotnet/extensions/blob/main/src/Libraries/Microsoft.Extensions.Caching.Hybrid/Internal/DefaultHybridCache.Stampede.cs

Consequently, when the L2 entry expires:

1. every instance whose L1 entry is also absent/expired can observe an L2 miss;
2. HybridCache coalesces concurrent callers inside each instance;
3. one factory per instance may still run at the same time.

HybridCacheEntryOptions.Expiration controls the L2/distributed absolute lifetime, while LocalCacheExpiration controls L1. A common setup is to keep L1 shorter than L2, so most L1 misses are served by the still-valid distributed entry:

var options = new HybridCacheEntryOptions
{
    LocalCacheExpiration = TimeSpan.FromMinutes(1),
    Expiration = TimeSpan.FromMinutes(10),
};

var value = await cache.GetOrCreateAsync(
    key,
    factory,
    options,
    cancellationToken: cancellationToken);

Microsoft's documentation describes L1 as separate per server and L2 as the configured IDistributedCache; it does not claim cross-process stampede protection:

https://learn.microsoft.com/en-us/aspnet/core/performance/caching/hybrid?view=aspnetcore-10.0#cache-storage

If duplicate regeneration across nodes is acceptable, no extra coordination is needed; the factories race and write equivalent values. You can reduce synchronized expirations with per-key expiration jitter.

If the factory is expensive or must execute only once globally, add coordination outside HybridCache, for example a Redis lease (SET key token NX PX ...) or a database advisory lock. The safe pattern is:

1. miss L1/L2;
2. acquire a bounded distributed lease using a unique owner token;
3. re-check L2 after acquiring the lease, because another node may have filled it while this node waited;
4. compute and populate the cache only if it is still absent;
5. release only if the stored token is still yours (atomic compare-and-delete), and account for lease expiry/fencing.

Do not use an unbounded lock, and do not assume a Redis lock alone gives exactly-once semantics during process pauses or network partitions. The underlying operation should still be idempotent when correctness matters.

There is a related multi-node caveat for invalidation: removing a key/tag updates the current server and L2, but it does not immediately evict that key from every other server's L1. For strict cross-node freshness, use short L1 lifetimes, versioned keys, or an explicit pub/sub invalidation mechanism.

If this answers the question, please mark it as the accepted answer so future readers can distinguish local stampede protection from a distributed lock.