How Distributed Locks Work
AdvancedA distributed lock lets multiple servers coordinate exclusive access to a shared resource — only one worker runs a job, only one process writes a file. Unlike an in-process lock, it must work across machines that can crash or lose network connectivity, which makes it surprisingly hard. The common approach is Redis SET NX with a TTL, but expiry and clock issues can let two holders think they own the lock, so critical systems add fencing tokens.
Think of a single bathroom key at a cafe
A cafe with one bathroom hands out a single physical key — whoever holds it has exclusive access, and everyone else waits. Now imagine the holder wanders off and never returns the key: the bathroom is locked forever. So the cafe adds a rule — the key auto-returns after 10 minutes (a TTL). But if someone is still inside when their 10 minutes expire and a new person grabs the key, two people think they have access. That awkward overlap is exactly the hard part of distributed locking.
Step by Step
Key Concepts
SET NX with TTL
The basic Redis lock: set the key only if absent (NX) with an expiry (PX). NX gives mutual exclusion; the TTL prevents a crashed holder from deadlocking the resource forever.
The Expiry Problem
If a lock TTL expires while the holder is still working (a long pause or GC), another worker can acquire it, leaving two holders. This is the core reason distributed locks are hard.
Fencing Token
A monotonically increasing number returned with each lock grant. The resource rejects operations with an out-of-date token, so a stale holder cannot cause damage even under overlap.
Redlock Debate
Redlock is an algorithm using multiple Redis nodes for stronger locks. Experts disagree on its safety; the consensus is that locks alone are not enough for correctness — pair them with fencing tokens.
Key Facts
- Always set a TTL, or a crashed lock holder deadlocks the resource permanently.
- A TTL introduces its own risk: work that outlives the TTL can result in two simultaneous holders — fencing tokens are the real fix.
- For strong correctness (leader election, config coordination), consensus systems like ZooKeeper or etcd are safer than a simple Redis lock.
Real-World Applications
Run a scheduled job once
In a cluster of identical instances, a distributed lock ensures only one instance runs a nightly batch job, instead of all of them running it and duplicating work.
Serialising updates to a resource
When several workers might update the same external file or record, a distributed lock (with a fencing token on the write) ensures only one modifies it at a time, preventing corruption.
Frequently Asked Questions
How do you implement a distributed lock with Redis?
Use SET lock_key unique_value NX PX ttl — set the key only if it does not exist (NX), with an expiry (PX). Acquiring the key means holding the lock; the TTL frees it if the holder crashes. Release by atomically deleting the key only if it still contains your unique value, so you never delete someone else lock.
Why are distributed locks considered hard?
Because the nodes involved can crash, pause (garbage collection), or be partitioned from the network. A TTL added to prevent deadlock can expire while a slow holder is still working, allowing a second worker to acquire the same lock — two holders at once. Guaranteeing true mutual exclusion across unreliable machines is fundamentally difficult.
What is a fencing token?
A monotonically increasing number issued with each lock grant. When the lock holder writes to the protected resource, it includes the token, and the resource rejects any write with a token lower than the highest it has already accepted. This protects against a stale holder corrupting data even if two processes briefly believe they hold the lock.
When should I use ZooKeeper or etcd instead of Redis for locking?
When correctness is critical — leader election, coordinating configuration, or exclusive access where a mistake is costly. Consensus systems like ZooKeeper and etcd provide stronger guarantees (via consensus protocols and session-based ephemeral nodes) than a simple Redis lock, which trades some safety for speed and simplicity.