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

```js
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:

```js
// 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?