---
title: "Discussion on \"System Design Drill Day 2: Caching, TTLs and Cache Stampedes\" | Hashnode"
description: "Discussion on \"System Design Drill Day 2: Caching, TTLs and Cache Stampedes\". How cache-aside caching with Redis works, how to choose TTLs, and how to stop a cache stampede from taking down your database."
url: "https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [System Design Drill Day 2: Caching, TTLs and Cache Stampedes](https://blog.anishansari.com.np/system-design-drill-day-2-caching-ttls-and-cache-stampedes?utm_source=hashnode&utm_medium=feed)

How cache-aside caching with Redis works, how to choose TTLs, and how to stop a cache stampede from taking down your database.

Oct 20 · 8 min read · blog.anishansari.com.np  
Read the article

-   [#redis](https://hashnode.com/tag/redis)
-   [#system-design](https://hashnode.com/tag/system-design)
-   [#caching](https://hashnode.com/tag/caching)
-   [#laravel](https://hashnode.com/tag/laravel)
-   [#interview-preparation](https://hashnode.com/tag/interview-preparation)

## Written by

[Anish Ansari](https://hashnode.com/@anish78)

@anish78 · kathmandu, Nepal

  
[View profile](https://hashnode.com/@anish78)

Food,Code and Cloud Computing. You can support here :https://www.buymeacoffee.com/anishansari

## Responses 7

Markdown supported · ⌘↵ to post

[mno tao](https://hashnode.com/@dancermno)

[Oct 21](https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b/comment/6ad81beb2731514e76afc31c)

One detail worth a line in the model solution: the lock's EX 5 has to outlast the slowest DB load you expect under promo traffic. If MySQL is already struggling and the query takes longer than 5 seconds, the lock expires, a second request takes it and also goes to the database, which is the herd starting again in slow motion. How long would you let the waiting requests retry before they fall back to MySQL themselves?

[Anish Ansari](https://hashnode.com/@anish78)

[Oct 21](https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b/comment/6ad81beb2731514e76afc31c#reply-6ad83d03da63380ac3bc87b5)

Good catch, the lock has to outlive your slowest expected load, otherwise it expires mid rebuild and a second request heads to MySQL. I'd keep the waiters retrying Redis for roughly the lock window and then serve the stale soft expiry copy if one exists, only falling back to MySQL when nothing is cached at all.

[Abhinav Sharma](https://hashnode.com/@abhinavs1920)

[Oct 20](https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b/comment/6ad7d77d000d92665d23aac3)

The soft TTL with background refresh is the nicest answer here, the herd never forms because only one worker rebuilds while everyone else serves the stale copy. Picking TTLs per data type instead of one global value is also the part people usually skip.

[Anish Ansari](https://hashnode.com/@anish78)

[Oct 21](https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b/comment/6ad7d77d000d92665d23aac3#reply-6ad83cf7a6d3354092a50cb7)

Thanks Abhinav, soft TTL is my favourite fix too because readers get a slightly stale copy and MySQL never sees the spike. And yes, per data type TTLs are where most of the real tuning happens.

[Abhinav Sharma](https://hashnode.com/@abhinavs1920)

[Oct 20](https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b/comment/6ad73c3752650cb3517d0510)

The jitter point deserves more attention than it gets. If every key gets the same TTL, they were all written in the same deploy and will expire together, so the herd reforms on a schedule. Even 10 percent randomness spreads the misses out enough to matter.

[Anish Ansari](https://hashnode.com/@anish78)

[Oct 20](https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b/comment/6ad73c3752650cb3517d0510#reply-6ad76a34dfa8da14174a8239)

Thanks Abhinav, keys written in the same deploy expiring together is exactly how it bites in practice. A little jitter turns one big stampede into a trickle the database can handle.