Distributed Locks and Leases Deep Dive
A 5-question reference set on distributed mutual exclusion: Redis SETNX with fencing tokens, etcd leases, Raft leader election, optimistic vs pessimistic locking tradeoffs, and cross-region home-region pinning.
Question Bundle
Java
distributed-systems
consensus
concurrency
interview-prep
By CodeSnatch
November 24, 2025
·
Updated August 12, 2026
702 views
7
Rate
A naive distributed lock uses Redis SETNX to acquire a key. What edge cases does this break in, and how does adding a fencing token fix the worst one?
Examples
Example 1:
Input: Client A acquires lock 'k', then GCs for 30s, then resumes thinking it still holds the lock
Output: During the GC, lock TTL expires; client B acquires 'k'; A and B both write
Explanation: Process-pause-longer-than-TTL is the classic Redlock failure mode; SETNX alone cannot detect it.Example 2:
Input: Storage layer enforces monotonically-increasing fence token on every write
Output: A's write with token=42 is rejected because B's write with token=43 has already landed
Explanation: Fencing tokens make stale lockholders harmless at the storage layer; locks become advisory + tokens authoritative.4 more questions and all solutions are locked.
Purchase this item to access all questions, code snippets, and solutions.