Discussion on "System Design Drill Day 8: Distributed Locks with Redis and Fencing Tokens"

Anish Ansari · 2026-10-26T03:11:17.398Z

One unit of a hot SKU is left, and two customers press "Buy" at the same moment on two different app servers. Both see "1 in stock", both checkouts succeed, and one of them gets an apology email. A mu

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.

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.

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

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.

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.

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.

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.

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.

Search Hashnode

System Design Drill Day 8: Distributed Locks with Redis and Fencing Tokens

Responses10