How do distributed locks work with Redis?

Question

Accepted Answer

A **distributed lock** coordinates access to a shared resource across multiple processes/servers so only one holds the lock at a time. Redis is commonly used for this via atomic set-if-not-exists with a TTL — though doing it correctly requires care (and understanding the limitations).

## A basic Redis lock (SET NX with TTL)

```js
// acquire: SET the lock key only if it doesn't exist, with a TTL (auto-release safety)
const token = randomUUID();   // a unique token identifying THIS lock holder
const acquired = await redis.set("lock:resource", token, "NX", "EX", 30);
// NX = set only if not exists (atomic); EX 30 = auto-expire in 30s (avoid deadlock)

if (acquired) {
  try {
    // ... do the work that needs exclusive access ...
  } finally {
    // release ONLY if WE still hold it (check the token) — use a Lua script for atomicity
    await releaseLock("lock:resource", token);
  }
}
```

The lock uses **`SET key value NX EX`**: atomically set the key only if absent (so only one client succeeds) with a **TTL** (so the lock auto-releases if the holder crashes, avoiding deadlock).

## Two critical correctness details

```text
1. ALWAYS set a TTL → if the lock holder crashes, the lock auto-expires
   (otherwise the resource is locked forever — a deadlock)
2. Use a UNIQUE TOKEN + release only if it matches → so you don't release
   SOMEONE ELSE'S lock (e.g. if your TTL expired and another client acquired it).
   Release must be ATOMIC (check-token-then-delete via a Lua script).
```

```lua
-- safe release: delete only if the value matches our token (atomic via Lua)
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end
```

## Limitations and Redlock

```text
⚠️ A single-Redis lock isn't perfectly safe: if the TTL expires mid-work, or with
   failover (the lock not yet replicated), two clients could both hold it.
→ REDLOCK algorithm → acquire the lock across MULTIPLE independent Redis nodes
   (majority) for stronger guarantees (though even Redlock is debated).
→ For critical correctness, combine with fencing tokens or use a system designed for
   consensus (e.g. ZooKeeper/etcd). Know the trade-offs.
```

## Why it matters

Understanding distributed locks with Redis is valuable for **coordinating access to shared resources** across distributed systems, so it's useful knowledge — and understanding the correctness pitfalls is especially important.

Distributed locks address a real need: ensuring only one process/server performs a critical action at a time (preventing duplicate processing, race conditions on shared resources, or conflicting operations) in multi-server systems, and Redis is a common tool for this.

Understanding the **basic mechanism** — `SET key value NX EX` (atomic set-if-not-exists with a TTL) so only one client acquires the lock and it auto-releases on crash — is the foundational technique.

Critically, understanding the **two correctness details** is essential: **always using a TTL** (so a crashed holder's lock auto-expires, avoiding permanent deadlock) and **using a unique token with matched release** (so you don't accidentally release another client's lock if your TTL expired — with atomic check-then-delete via a Lua script).

These details are where naive implementations have subtle, dangerous bugs.

Equally important is understanding the **limitations**: a single-Redis lock isn't perfectly safe (TTL expiry mid-work or failover can let two clients hold it), leading to the **Redlock** algorithm (acquiring across multiple Redis nodes) for stronger guarantees — and knowing that for critical correctness, fencing tokens or consensus systems (ZooKeeper/etcd) may be needed.

This awareness of the trade-offs and limitations reflects mature understanding.

Since coordinating shared-resource access in distributed systems is a real need, and since Redis distributed locks are common but require careful correct implementation (TTL, unique token, atomic release) and awareness of their limitations (Redlock, failover risks), understanding distributed locks with Redis — the mechanism, the correctness details, and the limitations — is valuable, practically-relevant knowledge for distributed coordination, a topic where understanding the pitfalls and trade-offs is as important as the basic technique.