Add new blog post on Redis TTL, Jitter, and server stability (#90)

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

@@ -0,0 +1,108 @@
+---
+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?