When a frequently requested cache entry expires, the next request can trigger a slow read from the database and a cache update. Refresh-ahead avoids that latency by acting before expiration. section 7.6
The policy identifies popular entries that are about to expire, then asynchronously reads their current values from the main source and updates the cache. Requests continue using the cached value instead of waiting for database access. section 7.6
Apply refresh-ahead when the workload and consistency model support it:
- Prefer entries with high request frequency, because proactive work is most valuable when it prevents repeated cache misses. section 7.6
- Accept slight staleness, as in eventually consistent systems where cached data may lag the database briefly. section 7.6
- Compare the policy with Read-Through and Cache-Aside, and avoid choices that overload the database or main storage. section 7.6
Shopping-cart availability
A shopping cart can tolerate an entry being slightly out of sync for roughly 100 milliseconds or even a second. Refresh-ahead can update a popular entry in the background while serving the existing cached value. section 7.6
