CacheInterceptor TTL Expiration and Cache Stampede Prevention

Answer

To prevent a cache stampede when the TTL expires, wrap the CacheInterceptor logic with a per‑key lock (or use a cache that supports refresh‑after‑write) so only one request reloads the value while others receive the stale entry.

Confirmed facts

• CacheInterceptor delegates TTL enforcement to the underlying CacheManager (e.g., memory store, Redis) which automatically invalidates entries after the configured expireAfterWrite/expireAfterAccess.
• The interceptor itself does not provide stale‑while‑revalidate or request collapsing.
• Libraries such as Caffeine, EhCache 3, or Redis with Redisson expose built‑in refresh‑after‑write or probabilistic early expiration that reduces simultaneous rebuilds.

Likely explanation

Without native stampede protection, the interceptor treats an expired entry as a miss and lets every concurrent request call the provider. Adding a lightweight lock around the cache lookup ensures that only the first thread proceeds to reload; waiting threads either block on the lock or receive the stale value if you return it before releasing the lock.

Steps to implement (per‑key async mutex)

1. Install cache-manager and optionally cache-manager-ioredis if you use Redis.
2. Create a custom interceptor that extends CacheInterceptor (or re‑implements the intercept logic).
3. Maintain a Map<string, Promise<any>> or a AsyncMutex per cache key.
4. In intercept:
1. Attempt to get the cached value.
2. If present and not expired, return it.
3. If missing or expired, check the lock map for the key.
4. If no lock exists, create a promise that calls next.handle(), stores the result in the cache, and resolves.
5. Return the lock promise to all callers; only the first will execute the provider.
5. Provide a factory to clean up resolved promises (e.g., remove after settle) to avoid memory leaks.

Verification

• Enable DEBUG logging for nestjs/cache-interceptor (or cache-manager) and confirm that after TTL expiry only one miss → store sequence appears per key.
• Run a load test (e.g., with k6 or JMeter) that spikes requests for a key just before TTL expiry and measure that the provider is called once.
• Expose cache metrics via Micrometer (if using a Java‑based cache) or via cache-manager stats and verify that miss spikes are bounded.

Missing diagnostic detail

Are you using the default in‑memory store or a distributed store such as Redis? The locking approach differs: a local async mutex works for a single‑node memory cache, while a distributed lock (e.g., Redisson RLock) is needed for multi‑node Redis deployments.