---
title: "Discussion on \"System Design Drill Day 8: Distributed Locks with Redis and Fencing Tokens\" | Hashnode"
description: "Discussion on \"System Design Drill Day 8: Distributed Locks with Redis and Fencing Tokens\". How distributed locks work with Redis SET NX EX, why leases and fencing tokens matter, and where locks fit in a checkout."
url: "https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0"
---

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

Discussion

# [System Design Drill Day 8: Distributed Locks with Redis and Fencing Tokens](https://blog.anishansari.com.np/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens?utm_source=hashnode&utm_medium=feed)

How distributed locks work with Redis SET NX EX, why leases and fencing tokens matter, and where locks fit in a checkout.

Oct 26 · 10 min read · blog.anishansari.com.np  
Updated Oct 27  
Read the article

-   [#system-design](https://hashnode.com/tag/system-design)
-   [#distributed-systems](https://hashnode.com/tag/distributed-systems)
-   [#redis](https://hashnode.com/tag/redis)
-   [#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 10

Markdown supported · ⌘↵ to post

[melonape](https://hashnode.com/@melonape)

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6ae087f4a03d5cfc8f99a8ae)

For the last-unit case, the conditional update does the actual protecting: UPDATE ... SET qty = qty - 1 WHERE sku = ? AND qty >= 1, then check affected rows. Two servers can race all day and only one gets a row back.

The lock earns its keep one step earlier, so you don't charge the card and only then find out the stock is gone.

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

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6ae087f4a03d5cfc8f99a8ae#reply-6ae0a7f24be03282da42af65)

Spot on, the conditional UPDATE is what actually stops the oversell. The lock just saves you from charging a card for stock that's already gone.

[Crownforge](https://hashnode.com/@thecrownforge)

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6ae0790ad9806620b2758b28)

How would you recover if the Redis fencing counter is lost but MySQL still has a high fence\_token? Starting INCR from zero again would leave new holders unable to write until the counter catches up. That seems worth a recovery test alongside the stale holder test

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

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6ae0790ad9806620b2758b28#reply-6ae07c7087f3dfa3c629747f)

Fair question. I'd reseed the Redis counter from MAX(fence\_token) in MySQL before any lock is handed out again, and a test that wipes the counter and checks the next holder can still write is definitely worth adding.

[Ziwei Yao](https://hashnode.com/@vitayao)

[Oct 26](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6adf1e02559b843e076534ac)

Should lease acquisition and fencing-token allocation be atomic? With SET NX followed by a separate INCR, A could acquire, pause before INCR, and lose its lease. B acquires, gets token 1 and writes. A resumes, gets token 2, and its stale write passes fence\_token < :token. The stock check still prevents overselling, but does this break the stale-holder guarantee? I’d test a pause between those Redis commands.

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

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6adf1e02559b843e076534ac#reply-6ae027a05217df75cd4e3be3)

Good point Ziwei, asserting that the stale holder's write is rejected after the newer holder has written is the real fencing test. Stock staying non-negative can hide a broken fence, so I'll add that check.

[Ziwei Yao](https://hashnode.com/@vitayao)

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6adf1e02559b843e076534ac#reply-6ae060781b2db2d2f9307032)

A latch in the test could make the pause reproducible instead of depending on sleep timing. That would be a nice companion to the revised example.

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

[Oct 27](https://hashnode.com/posts/system-design-drill-day-8-distributed-locks-with-redis-and-fencing-tokens/6adec4d52d0de51d89be8ab0/comment/6adf1e02559b843e076534ac#reply-6ae07c7dd9806620b275a560)

Nice idea Ziwei, a latch makes the stale holder's pause deterministic instead of hoping a sleep lands in the right spot. I'll use that in the revised test.