Introduction

An async GetOrSet cache method should do more than just wrap a synchronous cache lookup in Task.Run. The real goal is to avoid blocking while computing the missing value and to prevent several callers from doing the same expensive async work at once. A good design therefore combines asynchronous factories with stampede protection.

Define the Async Contract Clearly

A typical async cache API takes:

• a cache key
• an asynchronous factory that produces the value on a miss
• optional expiration settings

The factory should return Task<T>, not T, so callers can await genuine asynchronous I O such as database or HTTP work.

Example with ConcurrentDictionary and Lazy<Task<T>>

One practical pattern is to use a ConcurrentDictionary that stores lazy tasks per key.

1using System;
2using System.Collections.Concurrent;
3using System.Threading.Tasks;
4
5public class AsyncCache<T>
6{
7    private readonly ConcurrentDictionary<string, Lazy<Task<T>>> _entries = new();
8
9    public Task<T> GetOrSetAsync(string key, Func<Task<T>> factory)
10    {
11        var lazy = _entries.GetOrAdd(
12            key,
13            _ => new Lazy<Task<T>>(factory)
14        );
15
16        return lazy.Value;
17    }
18}

Usage:

1var cache = new AsyncCache<string>();
2
3string value = await cache.GetOrSetAsync("user:42", async () =>
4{
5    await Task.Delay(100);
6    return "Ada";
7});
8
9Console.WriteLine(value);

The important property is that concurrent callers for the same key share the same in-flight task instead of starting duplicate work.

Handle Failures Carefully

If the factory throws, you often do not want to keep a failed task cached forever. One approach is to remove the entry on failure.

1public async Task<T> GetOrSetAsync(string key, Func<Task<T>> factory)
2{
3    var lazy = _entries.GetOrAdd(key, _ => new Lazy<Task<T>>(factory));
4
5    try
6    {
7        return await lazy.Value;
8    }
9    catch
10    {
11        _entries.TryRemove(key, out _);
12        throw;
13    }
14}

Without this, one transient error can poison the cache entry.

Calling the Async Cache Method

Callers should simply await it.

1string product = await cache.GetOrSetAsync("product:9", async () =>
2{
3    await Task.Delay(50);
4    return "Keyboard";
5});

Do not call .Result or .Wait() from synchronous code unless you have a very controlled environment. That defeats the async design and can cause thread-blocking problems.

If You Already Use IMemoryCache

In ASP.NET Core, IMemoryCache can be combined with async factories, but you still need to think about duplicate concurrent misses. A simple TryGetValue plus async set is not enough if many requests can race on the same key.

That is why stampede protection matters more than the surface signature of the method. The hard problem is not storing the value. It is coordinating concurrent cache misses safely.

Decide What Happens on Expiration and Refresh

A practical cache design also needs a policy for expiration and stale refresh. Async access changes the call shape, but it does not remove the need to choose when values expire, whether stale values may be served briefly, and how expensive refresh work is coordinated. Those decisions often matter more than the method signature itself.

Common Pitfalls

• Wrapping synchronous cache code in Task.Run and calling it async.
• Allowing several concurrent misses to invoke the expensive factory at the same time.
• Caching a failed task permanently after one exception.
• Calling the async cache method synchronously with .Result or .Wait().
• Forgetting expiration and invalidation just because the cache access became asynchronous.

Summary

• An async GetOrSet method should accept an async factory and return Task<T>.
• The main design challenge is preventing duplicate in-flight work for the same key.
• 'ConcurrentDictionary plus Lazy<Task<T>> is a practical stampede-protection pattern.'
• Failed tasks usually should be removed so retries can succeed later.
• The async method should be awaited end to end rather than forced back into synchronous calling code.