Cloud-Blog/content/blogs/7. redis-ttl-jitter-and-how-i-almost-crashed-a-server.md

title, date, description, image, alt, ogImage, tags, published

title	date	description	image	alt	ogImage	tags	published
Redis TTL, Jitter, and How I Almost Crashed a Server 🚀	18th Sep 2025	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.	/blogs-img/blog7.png	Redis TTL, Jitter, and How I Almost Crashed a Server 🚀	/blogs-img/blog7.png	redis ttl jitter	true

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?