109 lines
3.2 KiB
Markdown
109 lines
3.2 KiB
Markdown
---
|
||
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?
|