---
title: "Comment by mno tao on \"System Design Drill Day 2: Caching, TTLs and Cache Stampedes\" | Hashnode"
description: "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"
url: "https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b/comment/6ad81beb2731514e76afc31c"
---

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

Comment [System Design Drill Day 2: Caching, TTLs and Cache Stampedes](https://hashnode.com/posts/system-design-drill-day-2-caching-ttls-and-cache-stampedes/6ad732771e0bcca489a2809b)

[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.