What Happens When Redis Cache Expires?

Most systems feel fast… until the cache disappears.

This week, I ran a performance experiment to answer a simple question:

What really happens when Redis cache expires under load?

The answer is more surprising than expected — because the problem is almost invisible.

Experiment Setup

I built a simple test using:

• Spring Boot API
• Redis (TTL = 30 seconds)
• Simulated database delay (~100–300 ms)
• JMeter load test

Endpoint

GET /api/cache/test/1

All requests hit the same key — important to simulate real cache behavior.

Real Test Result (Production-like Load)

From JMeter Summary Report:

• Total Requests: 1,734,951
• Average Latency: 3 ms
• Max Latency: 556 ms
• Throughput: 14,462 req/sec

At first glance, everything looks perfect.

But there’s a problem hidden inside this result.

The Hidden Spike

Even though the average latency is only 3 ms, some requests took over 500 ms.

These slow requests happened exactly when:

• Cache expired
• Requests hit the database
• The cache was rebuilt

This is the moment where performance briefly collapses.

Why You Don’t See It

Because averages lie.

Out of 1.7 million requests, only a tiny fraction hit the database.

So:

• Avg = 3 ms
• Reality = occasional 500+ ms spikes

📊 Visualizing the Spike

Here’s what actually happens over time:

• Most requests: fast (cache hit)
• At TTL boundary: sudden spike
• Then back to normal

This creates a repeating pattern:

👉 Fast → Fast → Fast → 💥 Spike → Fast → Fast

I generated a dataset to clearly show this behavior.

Redis Cache Expiration Latency Spike

Simulated Spike Data (Clear View)

To make the behavior visible, I ran a controlled dataset:

• Baseline latency: 3–6 ms
• Expiration spike: 200–550 ms
• TTL: 30 seconds

This produces a clear latency wave:

• Stable performance
• Sudden spike at expiration
• Recovery

What’s Really Happening

At expiration time:

1. Cache entry disappears
2. All incoming requests miss the cache
3. Multiple requests hit the database
4. Latency spikes
5. Cache gets rebuilt

This is known as:

Cache Stampede

Why This Matters

In production systems:

• High traffic amplifies the problem
• Multiple services may expire at once
• Database gets sudden load spikes

This leads to:

• Unstable latency
• Performance degradation
• Hard-to-debug issues

The Most Important Lesson

Average latency hides real problems.

Your system may look fast:

• Avg = 3 ms

But users may experience:

• 300–500 ms delays

How to Measure It Properly

Instead of average, monitor:

• P95 latency ⭐
• P99 latency
• Cache hit ratio

These metrics reveal the real story.

How to Fix It

1. Add TTL Jitter

Duration.ofSeconds(30 + random.nextInt(10))

Prevents simultaneous expiration.

2. Use Cache Lock

Only one request rebuilds the cache.

3. Preload Cache

Refresh before expiration.

4. Serve Stale Data

Return old data while refreshing in the background.

Final Thoughts

Redis cache expiration is not just a cleanup process.

It’s a performance event.

And if you don’t measure it correctly…

You won’t even see it happening.

[embed]GitHub - nithidol/project-cache-pe Contribute to nithidol/project-cache-pe development by creating an account on GitHub.github.com

🔖 Thanks for reading.

• If you enjoyed this article, please consider giving it a clap.👏
• I would appreciate hearing your thoughts in the comments below! 💭
• Follow me for ongoing learning and connection!🔔