Is your feature request related to a problem? Please describe.

A frequent use case for caching is to reduce the number of expensive operations performed during web requests. However, sometimes data will change and to ensure we reach consistency we can expire cache entries after a period of time. The problem with this is that after the entry expires we will have a cache miss and the expensive operation will slow down at least one request (possibly many on a busy server).

Say our cached operation takes 5 seconds to complete, we need it to expire at least once per minute, and our instance is receiving 10 requests per second. Using the conventional expiry means as many as 50 requests per minute may be affected by the cache miss.

Describe the solution you'd like

I propose an alternative to the ExpiryDate, which I refer to as RefreshAfter. You set a short RefreshAfter time interval when you add your cache entry for a cache item that doesn't expire or has a long expiry. The RefreshAfter interval will be used to calculate the time after which the next refresh should occur (NextRefreshTime). When (time created/last updated - current time > NextRefreshTime) then the cache update operation (provided callback?) will be performed asynchronously one time in a thread-safe manner. End users will not be aware of this.

RefreshAfter provides no guarantee the cache will actually be refreshed at the NextRefreshTime, simply that it will be attempted at some point after that time. The refresh happens lazily and refresh rate will vary based on request frequency.

Ideally, in a distributed environment other instances will be aware the cache has been refreshed and push back their NextRefreshTime. Perhaps in a distributed cache each instance could track the time created/last updated and reset their own NextRefreshTime to a later date.

Describe alternatives you've considered

An alternative to this would be an eager approach to refreshing the cache, involving a background timer that would constantly attempt to refresh the cache at an interval. I consider this solution to be less useful as it would:

• be harder to work into a distributed cache system
• be harder to maintain/monitor/debug
• consume more system resources and lead to unnecessary refreshes at times of low traffic

Another alternative would be to re-include the UpdateCallback, but I saw this was intentionally dropped from the project (see below).

Additional context

Cache refreshing solutions have been proposed before:
http://pdalinis.blogspot.com/2013/06/auto-refresh-caching-for-net-using.html
https://stackoverflow.com/questions/44723017/in-memory-caching-with-auto-regeneration-on-asp-net-core
https://www.programmingmusings.com/index.php/2016/09/27/auto-refresh-thread-safe-cache-in-net/

UpdateCallback Request:
aspnet/Caching#31

And has been implemented in a popular library in Java:
https://github.com/google/guava/wiki/CachesExplained#refresh