When a Redis Lock Is Enough, and When It Isn't

`SET NX EX` against a single Redis instance is simple and works for most cases: acquiring a lock, setting a TTL so it self-expires if the holder crashes, releasing it when done. The failure mode is the TTL itself. If the job holding the lock runs longer than the TTL, network hiccup, GC pause, slow downstream call, the lock expires while the job still thinks it holds it, and a second client can acquire it and start the same work concurrently. A watchdog thread that extends the TTL while the job is still alive closes most of this gap, but adds its own complexity.

Redlock acquires the lock across a majority of independent Redis instances instead of one, which is meant to survive a single instance failing or partitioning. Martin Kleppmann's well-known critique of the algorithm points out that it still doesn't protect against the TTL-expiry problem above, a process pause can make a client believe it holds the lock after it's actually expired regardless of how many instances agreed to grant it. Redlock buys you resilience against a single Redis node going down; it does not buy you a correctness guarantee against process pauses, and teams that adopt it expecting the latter are solving the wrong problem.

A fencing token is a monotonically increasing number returned with each lock acquisition, and every downstream system the lock protects, the database write, the API call, checks that the token it's seeing is the highest one it's seen before accepting the operation. This means even if two clients briefly both believe they hold the lock, only the one with the higher token's operations get accepted downstream. This requires the protected resource to support the check, which a Redis lock alone can't guarantee, so it's an added integration point, not a drop-in fix.

If the work you're protecting already happens inside a transaction against your primary database, Postgres's `pg_advisory_lock` or a `SELECT ... FOR UPDATE` often does the job with fewer moving parts and no separate infrastructure to reason about. It's scoped to the database session, tied to the same transaction boundary as the work itself, and doesn't introduce a second system that can fail independently. Reach for Redis-based locking when the work spans multiple services or systems that don't share a transaction, not as a default for anything that needs mutual exclusion.

Whatever mechanism you pick, the job it protects should be idempotent, safe to run twice, wherever possible, so a lock failure degrades to "did the work an extra time" instead of "corrupted state." A distributed lock is a mitigation for a race condition, not a substitute for making the underlying operation safe to retry. Teams that treat the lock as the only line of defense are one clock skew or GC pause away from the exact failure they built the lock to prevent, which is why the idempotency work is worth doing even after the locking mechanism itself looks solid.

Match the mechanism to what a failed lock would cost you:

• Single-instance SET NX EX lock: simple and fine for most cases, but watch for a TTL that expires while the job is still running.
• Redlock: acquires the lock across a majority of independent Redis instances to survive one instance failing or partitioning.
• Fencing tokens: a monotonically increasing number that every downstream system checks, accepting only the highest token it has seen.
• Database advisory lock or SELECT FOR UPDATE: often enough when the protected work already runs inside a transaction on your primary database.
• Idempotent jobs: make the work safe to run twice, so a lock failure means duplicated effort instead of corrupted state.

Simulate the failure you're actually worried about in a lower environment: kill the process holding the lock mid-job and watch whether a second worker correctly picks up the work, or pause a process artificially to see whether its lock expires while it still believes it holds it. Most teams only discover their locking strategy has a gap during a real incident, when the failure mode is expensive to diagnose under pressure instead of cheap to reproduce deliberately ahead of time. A short, repeatable chaos test for your specific locking library is worth more than reading another article about Redlock's theoretical edge cases.