Distributed Locks with Redis
7 questions found
What is a distributed lock, and why would an application need one when using Redis?
Beginner
A distributed lock ensures that only one process or server, out of potentially many running the same application, can perform a specific action at a time, which is important when multiple application instances share access to a common resource and you need to prevent them from all trying to modify it simultaneously.
SET lock:inventory:product123 'owner1' NX EX 10
Real-world example
An order processing system running on several servers uses a distributed lock to ensure only one server at a time updates a specific product's inventory count, preventing two servers from accidentally overselling the same limited stock.
Common follow-ups: What happens if the process holding the lock crashes before releasing it?;How is a distributed lock different from a lock used within a single application process?
Rate Limiting with Redis;Session Management with Redis
How do you implement a basic distributed lock in Redis using the SET command with NX and EX options?
Beginner
You use the SET command with the NX option, which only sets the value if the key does not already exist, combined with the EX option to set an automatic expiration time, ensuring the lock is both exclusively acquired by only one client and automatically released after a timeout even if that client crashes before releasing it manually.
SET mylock 'unique_value_123' NX EX 30
-- If this returns OK, you have acquired the lock
-- If it returns nil, someone else already holds it
Real-world example
A batch processing job attempts to acquire a lock before starting its work, and if the lock already exists because another instance is currently running, it simply skips its turn and tries again during its next scheduled run.
Common follow-ups: Why is it important to set a unique value rather than just a fixed string like 'locked'?;What happens if the operation protected by the lock takes longer than the expiration time?
Distributed Locks with Redis;Redis CLI & Basic Commands
Why is it important to release a distributed lock using a script that verifies you are actually the current lock owner, rather than a simple DELETE command?
Intermediate
If you simply delete the lock key without checking first, you risk accidentally releasing a lock that was actually acquired by a different client after your own lock expired, so you should use a Lua script that checks the lock's value matches your unique identifier before deleting it, ensuring you only ever release a lock you actually still own.
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('del', KEYS[1])
else
return 0
end
Real-world example
A payment processing service uses a Lua script to safely release its distributed lock, preventing a rare but serious bug where a slow process could have accidentally deleted a lock that had already been acquired by a different, newer process.
Common follow-ups: Why must this check and delete operation happen atomically in a single script?;What happens if the lock has already expired by the time you try to release it?
Lua Scripting;Distributed Locks with Redis
What happens if the process holding a distributed lock crashes or hangs before it finishes its work and releases the lock?
Intermediate
This is exactly why a distributed lock should always be set with an expiration time, ensuring that even if the holding process crashes, hangs, or otherwise never explicitly releases the lock, it will automatically become available again after the timeout, preventing the resource from being permanently locked forever due to a single failure.
SET mylock 'owner_id' NX EX 30
-- Even if the owning process crashes,
-- this lock automatically expires after 30 seconds
Real-world example
A data processing job that unexpectedly crashed while holding a lock does not permanently block future job runs, since the lock's expiration time ensures it becomes available again automatically a short time later.
Common follow-ups: How do you choose an appropriate expiration time that is neither too short nor too long?;Can you extend a lock's expiration time if the protected operation is taking longer than expected?
Distributed Locks with Redis;Redis CLI & Basic Commands
What is the Redlock algorithm, and why was it proposed for implementing distributed locks across multiple independent Redis instances?
Advanced
The Redlock algorithm acquires a lock across a majority of several independent Redis instances rather than relying on just one, aiming to provide stronger guarantees against a single Redis instance failure incorrectly causing a lock to be lost or duplicated, though it has also been the subject of debate among distributed systems experts regarding whether it fully guarantees correctness in every failure scenario.
-- Acquire the same lock key across five independent
-- Redis instances, requiring a majority to succeed
-- before considering the lock successfully acquired
Real-world example
A financial trading system requiring extremely strong locking guarantees implements the Redlock algorithm across five independent Redis instances, accepting the added complexity in exchange for greater resilience against a single instance failure.
Common follow-ups: What are the criticisms that have been raised against the Redlock algorithm's correctness guarantees?;Is Redlock necessary for most typical applications, or is a simpler single instance lock usually sufficient?
Distributed Locks with Redis;Redis Sentinel & High Availability
How would you design a distributed lock implementation that supports safely extending the lock's expiration time if the protected operation needs more time than originally expected?
Advanced
You would implement a renewal function using a Lua script that checks the requesting client still owns the lock by matching the stored value, and if so, extends the key's expiration time atomically, allowing a long running process to periodically renew its lock while it is still actively working, without risking accidentally extending a lock it no longer actually owns.
if redis.call('get', KEYS[1]) == ARGV[1] then
return redis.call('expire', KEYS[1], ARGV[2])
else
return 0
end
Real-world example
A long running video processing job periodically renews its distributed lock every few seconds while actively working, ensuring the lock does not expire prematurely during an unusually large video file that takes longer than the original lock duration.
Common follow-ups: How often should a long running process renew its lock to stay safe?;What happens if the renewal call itself fails due to a network issue?
Lua Scripting;Distributed Locks with Redis
What are some common mistakes developers make when implementing distributed locks with Redis, and how do you avoid them?
Intermediate
Common mistakes include forgetting to set an expiration time, which risks a permanently stuck lock if a process crashes, using a non unique lock value, which can lead to accidentally releasing someone else's lock, and setting an expiration time too short relative to how long the protected operation actually takes, causing the lock to expire while the work is still in progress.
-- Always combine NX and EX together,
-- and always use a unique value per lock attempt
SET mylock 'unique_id_' || RANDOM() NX EX 30
Real-world example
A team debugging an intermittent data corruption issue discovers their distributed lock implementation was missing an expiration time entirely, causing occasional permanently stuck locks whenever a process crashed unexpectedly.
Common follow-ups: How do you test a distributed lock implementation for these kinds of edge cases?;What monitoring can help detect stuck or improperly released locks in production?
Distributed Locks with Redis;Redis Monitoring & Observability