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

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.

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

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.