Senior · Redis with Go
Leases, fencing and stale owners
Does SET key token NX PX make a perfect distributed lock?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
It creates a bounded lease under the chosen Redis deployment and failure assumptions. Expiry allows recovery but can also allow a second owner while the first is paused and later resumes.
Release must compare the random ownership token before deleting, atomically; a plain DEL can remove a newer owner's lease. Renewal must verify ownership and still cannot force an expired old process to stop.
Protect correctness at the resource with fencing/version checks or an idempotent operation when possible. Evaluate replication/failover assumptions and clock/timing behavior. Do not use a lease as a universal transaction substitute.
Common trap
A unique token makes release safer; it does not itself prevent a stale owner from writing to another system.
Try it
Worker A pauses beyond TTL; B acquires the lease; A resumes. Who may write?
Worked solution
The authoritative resource must reject A's stale generation/fencing token or reconcile duplicate operations. Without that protection, both processes can act despite a well-written token-safe release script.
Change the constraint
What guarantees would you lose during a failover that drops the lock write?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.