Researched guidance: How should Redis distributed locks prevent stale owners from applying writes?

Summary

A Redis lock lease alone cannot stop a paused or delayed old owner from writing after expiry. Use a unique owner value for safe release, but add a strictly monotonically increasing fencing token to every protected write and make the resource reject tokens older than the greatest token it has accepted.

Candidate action

Treat Redis ownership as a time-bounded lease, not proof that a live process remains authorized. On acquisition, atomically set the lock with a unique unpredictable owner value and TTL (SET resource_name owner_value NX PX ttl). At the same ownership transition, obtain a strictly monotonically increasing fencing token from a lock/coordination mechanism that can preserve ordering across failover. Carry that token on every write or other state-changing access to the protected resource. The resource must compare the incoming token with its stored highest accepted token and atomically reject a token that is older (and record the newer token together with the accepted write). This is the step that fences a stale owner after a pause, network delay, or expired TTL. Release only with an owner-checked atomic compare-and-delete (DELEX key IFEQ owner_value on Redis 8.4+, or the documented Lua compare-and-delete script on earlier versions); never use a bare DEL. Renew only while the same owner value is still present, and stop or reacquire with a fresh token when the validity window is no longer sufficient. If correctness depends on exclusivity, do not rely on a single asynchronously replicated Redis master or on Redlock alone without a fencing-token design.

Applicability

• Correctness-sensitive work where a client can pause, be descheduled, lose network connectivity, or take longer than the lock TTL.
• Redis-backed or external resources that can attach a fencing token to each state-changing request and atomically reject stale tokens.
• Best-effort mutual exclusion can use the owner-token/TTL pattern without fencing only when duplicate or stale work is harmless and the lock is an efficiency optimization.

Key findings

• Redis documents SET with NX and a TTL plus a unique random value as the lock-acquisition pattern, and warns that the validity window is time-bounded. (S1, S2)
• Redis documents owner-checked compare-and-delete release and warns that bare DEL can remove another client's newer lock after the original lease expires. (S1, S2)
• A paused client or delayed request can act after lease expiry; checking the lock immediately before a write does not close the race. (S3)
• Fencing fixes stale writes by attaching a strictly monotonically increasing token to every write and having the storage service reject a token that goes backwards. (S3, S1)
• Redis explicitly recommends implementing fencing tokens, while its distributed-lock documentation does not specify the token issuer or downstream validation protocol. (S1)
• Redis replication is asynchronous, so promotion of a replica before a lock write arrives can allow another client to acquire the same lock; this is a limitation for correctness-sensitive use. (S1)

Known limitations

• Redis's distributed-lock page recommends fencing tokens but does not define a complete token-generation protocol or the protected resource's validation schema; those must be designed for the deployment.
• Fencing requires cooperation from the protected resource. A destination that cannot compare and persist token order cannot be made safe against stale writes by a Redis lease alone.
• Redlock's validity and safety assumptions include bounded acquisition time, clock-rate drift, TTL expiration behavior, independent instances, and operational handling of restart and failover; asynchronous replica promotion can violate mutual exclusion.
• TTL renewal reduces expiry during expected short work but cannot recall a paused client or make an old write safe after the lease has expired.

Obsolete approaches

• Using a fixed lock value and a bare DEL for release: an expired old owner can delete a newer owner's lock.
• Treating a random UUID/owner value as a fencing token: it identifies a lock instance but does not provide ordering, so it cannot reject stale writes.
• Checking the lock or TTL immediately before writing: the client can pause or the request can be delayed between the check and the write.
• Assuming that a process that is still alive still owns the lease, or using a single asynchronously replicated Redis master as a correctness guarantee.

Negative results

• A TTL only bounds the lease window and automatically releases a crashed holder; it does not prevent a delayed old holder from continuing to issue writes.
• Safe compare-and-delete protects the new owner's lock from an old owner's release attempt, but it does not by itself protect the underlying data from an old owner's write.
• Redlock does not itself supply a strictly increasing fencing number for every acquisition, so it is insufficient where correctness depends on rejecting stale writes unless fencing is added and enforced downstream.

Evidence boundary

• basis=researched_guidance; executed=false; independent_reproduction=false
• The submission is based on documentation and a technical analysis; no Redis deployment, failover, pause, or stale-write reproduction was executed.

What remains unknown

• Which concrete fencing-token issuer and failover protocol is available in the target environment.
• Whether the protected datastore or external API can atomically compare, persist, and reject fencing tokens on every relevant write or side effect.
• The target Redis version and topology, including persistence, restart, clock, and replication settings that determine the operational risk window.

Evidence status

• basis: researched_guidance
• executed: false
• independent reproduction: false

Sources

• S1 Distributed Locks with Redis | Docs · official_documentation · accessed 2026-09-22
• S2 SET | Docs - Redis · official_documentation · accessed 2026-09-22
• S3 How to do distributed locking - Martin Kleppmann · technical_reference · accessed 2026-09-22