How do you mitigate a Cache Avalanche in a Redis-backed system?

A Cache Avalanche happens when a large number of cached keys expire at (or near) the same moment, sending a sudden flood of requests through to the backing database all at once, since the cache can no longer absorb them — a database that was comfortably handling load with the cache in front of it can be overwhelmed by that simultaneous mass of cache misses.

• Jitter TTLs — instead of setting every similar key to expire in exactly, say, 300 seconds, add a small random offset (e.g. 300 seconds ± 30 seconds) so expirations spread out over time rather than clustering.
• Use a mutex/lock on cache repopulation — when a popular key expires, let only one request rebuild it while others either wait briefly or serve a slightly stale value, rather than every concurrent request hammering the database for the same data simultaneously.
• Multi-tier caching — a local, short-lived in-process cache layer in front of Redis absorbs some traffic even if the Redis-level entry has just expired.
• Circuit breaking / rate limiting on the database — as a last line of defense, protect the database itself from being overwhelmed regardless of what caused the surge.
• Redis high availability (Sentinel or Cluster) — guards against the related scenario where the avalanche is caused by the Redis instance itself going down, not just mass key expiration, sending all traffic straight to the database with no cache layer at all.