Redis TTL, Jitter, and How I Almost Crashed a Server 🚀

Recently, I ran into an interesting Redis case that taught me a big lesson: Infinite cache TTLs are like hoarding—things pile up until it’s a problem.

The Setup: Infinite Cache

Once upon a time (okay, just a few months ago), we were saving some data in Redis with no expiration. The idea was simple:

Data comes from another system (the real source of truth).
We cache it in Redis for fast access.
Done. Easy. ✅

But here’s the problem: when you never expire cache, it keeps growing. And growing. And growing. Like that drawer in your house where you throw every cable you’ve ever owned.

The Task: Add a TTL

One day, I got the task:

“Please set a TTL of two weeks for this cache.”

Sounds easy, right? Just add:

redis.set('mykey', value, 'EX', 1209600) // 2 weeks in seconds

Boom. Done. Task finished. Go get coffee. ☕

Except… not really.

The Problem: Cache Avalanche

Think about what happens two weeks later. Every single cached key expires at the same time.

Suddenly, Redis says:

“Sorry boss, no cache here!”

And then our poor backend server (the real source of truth) gets flooded with requests, like:

HELP! SEND DATA! SEND DATA! SEND DATA!

The server could literally crash under the unexpected load. This is called a cache avalanche.

The Solution: Add Jitter

The trick is simple but powerful: don’t let all keys expire at once.

Instead of setting exactly 2 weeks, we add a little randomness (aka jitter). For example:

// Expire between 14 and 16 days
const baseTTL = 14 * 24 * 60 * 60 // 14 days
const jitter = Math.floor(Math.random() * (2 * 24 * 60 * 60)) // up to 2 days
const ttl = baseTTL + jitter

redis.set('mykey', value, 'EX', ttl)

Now some keys expire in 14 days, some in 15, some in 16. Which means requests trickle back to the server instead of hitting it like a tsunami. 🌊

Why It Matters

Without jitter:

Day 14 → server gets millions of requests at once. Boom. 🔥

With jitter:

Day 14 → some requests
Day 15 → some more
Day 16 → a few more
Server is chill. 😎

This small change can save your entire system from crashing.

Final Thoughts

Caching is powerful, but it comes with hidden gotchas.

Infinite TTL? Your cache becomes a junkyard.
Fixed TTL? Your server might collapse in 14 days like a time bomb.
TTL with jitter? Balanced, safe, and production-ready.

So the next time you set a cache TTL, remember: 👉 Always sprinkle some randomness in your Redis life.

Your future self (and your backend servers) will thank you. 🙏

Do you want me to also add a diagram (ASCII or image idea) showing the difference between no jitter vs jitter so it’s more visually clear for the blog?