---
title: "Comment by Arnold Holm on \"Redis Patterns Every Backend Engineer Should Know\" | Hashnode"
description: "One failure case worth adding to the cache example: the fetch takes longer than the five-second lock. A second worker acquires a new lock, then the first worker"
url: "https://hashnode.com/posts/redis-patterns-every-backend-engineer-should-know/6abe320c8c269df6ae50774c/comment/6ad3273baa3b1b23226fda9c"
---

[Discussion](https://hashnode.com/posts/redis-patterns-every-backend-engineer-should-know/6abe320c8c269df6ae50774c)

Comment [Redis Patterns Every Backend Engineer Should Know](https://hashnode.com/posts/redis-patterns-every-backend-engineer-should-know/6abe320c8c269df6ae50774c)

[Arnold Holm](https://hashnode.com/@stratcorealpha)

[Oct 17](https://hashnode.com/posts/redis-patterns-every-backend-engineer-should-know/6abe320c8c269df6ae50774c/comment/6ad3273baa3b1b23226fda9c)

One failure case worth adding to the cache example: the fetch takes longer than the five-second lock. A second worker acquires a new lock, then the first worker's finally block deletes it. The unique token and compare-and-delete from section 4 would protect this path too. A test with a deliberately slow fetch would make the difference visible.