Redis SET NX EX vs Redlock — Single-Instance Safety & the Kleppmann Debate

Overview

SET key token NX EX ttl is an atomic best-effort lock on a single Redis: acquire if absent, unlock only with a matching token via Lua. Redlock spreads that idea across N independent Redis nodes for majority quorum — but clocks, GC pauses, and correlated failures make it a poor choice for correctness-critical mutual exclusion.

Prefer single Redis + fencing for soft coordination. Prefer etcd / ZooKeeper / DB CAS when safety matters.

You should be able to:

1. Explain why NX and EX must be one command.
2. Contrast single-instance Redis with a consensus lock without re-teaching Raft.
3. Refuse Redlock for money, inventory, or unique constraints.

Atomic SET NX EX

Redis SET with NX (only if Not eXists) and EX/PX (TTL) is one round-trip and atomic on one server:

SET lock:ledger <random-token> NX PX 10000

• Success → you hold the lease for ~10s.
• Unlock must be compare-and-delete: only delete if value == your token (Lua), or you delete someone else's lock after expiry/reacquire.

flowchart TB
  a["1 Client A"]
  r["2 Redis"]
  b["3 Client B"]
  a -->|SET lock:x| r
  r -->|OK| a
  b -->|SET lock:x| r
  r -->|nil not acquired| b
  a -->|EVAL unlock if| r
  r -->|1| a

Unlock with token + Lua

Never DEL blindly:

-- KEYS[1]=lock key, ARGV[1]=token
if redis.call("GET", KEYS[1]) == ARGV[1] then
  return redis.call("DEL", KEYS[1])
else
  return 0
end

A random token exists so unlock only clears your lock if the key was reacquired after expiry by someone else. GET+DEL must be atomic; otherwise two clients can interleave and delete the wrong lock.

Clock and process assumptions (single instance)

Single-instance Redis lock is not consensus. It is useful for cache stampede coalescing and best-effort jobs if the shared resource is fenced or the work is idempotent. Stampede waiter behavior is single-flight.

What is Redlock?

Antirez's Redlock algorithm:

1. Get time t1.
2. Sequentially SET NX PX on N independent Redis masters (often 5).
3. Count successes; need majority (N/2+1).
4. Validity time ≈ TTL − (t2−t1) − clock drift.
5. Unlock: release on all nodes (best-effort).

Goal: survive minority Redis failures without a single coordinator.

Kleppmann: pauses and clock assumptions break safety; a majority of independent Redis is not the same as consensus; use fencing or a real consensus service for critical sections.

Defense: improves availability vs one node for soft locks; many workloads are best-effort; fencing can be added.

When is Redlock the wrong answer? Any time losing mutual exclusion corrupts money, inventory, or unique constraints — interviewers expect etcd/ZK/DB.

Do not "fix" multi-node Redis by inventing another Redlock. Put the lock in etcd/ZK or use DynamoDB conditional writes / Postgres row versions. Depth: ZK/etcd, CAS.

Leader election for soft leadership (cache warmer) maybe; for metadata ownership use Raft-based systems — see Raft hub, not this page.

Redis Cluster

Hash-tag the key to one slot. During resharding/failover expect weaker guarantees — another reason fencing matters.

Renew

PEXPIRE only if GET still equals your token (Lua). On renew failure: stop writing immediately. Depth: lease renewal.

Export acquire latency, acquire failures, hold duration, unlock mismatches, renew failures, fence rejects downstream.

Sandbox: token unlock vs bare DEL (Python)

In-memory Redis. After A's TTL, B acquires. A's late DEL would steal B's lock; token compare-and-delete would not.

Press Run. Snippets must be self-contained — no network, files, or native modules.

Same idea (TypeScript)

Press Run. Snippets must be self-contained — no network, files, or native modules.

Pitfalls

Interview Q&A

Go Deeper

• Kleppmann — How to do distributed locking
• Redis SET
• Redis distributed locks / Redlock
• Antirez — Is Redlock safe?
• Jepsen
• Next: ZooKeeper / etcd lock recipes