Every cache pattern so far accepts that cache misses happen: a key expires, a request misses, and someone pays the cost of reloading from the database. Refresh-ahead attacks that directly. Instead of waiting for a hot key to expire and then reloading it (while a user waits), it refreshes the key in the background before it expires, so the cache is always warm for the data that matters. It's a more advanced pattern, worth it for a specific case: predictable, frequently-accessed data where you never want a user to eat a cache miss.
This is part 12 of the Redis Masterclass, following write-behind.
The problem with expire-then-reload
In cache-aside, a cached key lives until its TTL, then expires. The next request misses and has to reload from the database synchronously, so that unlucky request is slow. For most data that's fine, the occasional slow request is a reasonable price. But for very hot keys (a homepage's featured content, a popular product, a config every request reads) that periodic slow reload happens constantly, and each time a real user waits for the database. Worse, if many requests hit the expired key at once, they all reload together, a stampede.
Refresh-ahead's insight: for data you know will be requested again, don't wait for it to expire. Refresh it proactively while it's still valid, so requests always hit a warm cache.
