Redis Lock, Postgres Advisory Lock, or Zookeeper: Picking One

Before picking a mechanism, be specific about the failure you are preventing. If two workers processing the same queue item just means duplicate work that gets deduplicated downstream, a lock with a small correctness gap under partition is tolerable. If it means double-charging a customer or corrupting a ledger, you need a mechanism with a real fencing token, not just a lock that two processes might both briefly believe they hold. Most teams reach for a lock without first writing down which of these two situations they are in.

A single-instance Redis lock using SET with NX and an expiry is simple and fast, and fine for low-stakes coordination like preventing a duplicate cron run. The multi-instance Redlock algorithm, meant to survive a single Redis node failing, has known edge cases around clock drift and process pauses that can let two clients both believe they hold the lock during a garbage collection pause or a slow network. If the cost of a double-execution is genuinely low, plain Redis locking is a reasonable, fast default. If it isn't, don't reach for Redlock as your safety net; reach for a mechanism with an explicit fencing token instead.

If your system already runs Postgres, an advisory lock, acquired with pg_advisory_lock or its transaction-scoped variant, gives you coordination without adding a new piece of infrastructure to operate. It is tied to a single database session, so it is naturally released if that connection drops, which avoids one whole class of stuck-lock incidents that plague expiry-based systems. The real limitation is scale: every lock holder needs an open database connection, which competes with your regular connection pool, so this fits background jobs and scheduled tasks far better than a high-concurrency request path.

Zookeeper and etcd were built specifically for this problem and provide real fencing tokens: a monotonically increasing number attached to each lock grant that a downstream system can use to reject a stale write from a client that lost and regained the lock. This is the right tool when the failure mode is financial or data corruption, not duplicate work. The tradeoff is operational: running and monitoring a Raft-based coordination cluster is a real ongoing cost, so most teams below a certain scale reach for a managed version, such as a cloud provider's hosted etcd, rather than self-hosting it.

• If a double-execution is cheap to detect and fix downstream, use a plain Redis lock.
• If you already run Postgres and the workload is background jobs rather than high-concurrency requests, use an advisory lock.
• If the cost of two holders believing they own the lock at once is real money or corrupted state, use a coordination service with a fencing token, and reject writes from stale tokens at the point of write, not just at the point of lock acquisition.

Teams most often get this wrong by defaulting to Redlock for the third case because it was already in the stack, without reading the specific edge cases that make it unsuitable there.

Picture a worker that acquires a lock, then stalls for an unusually long garbage collection pause, long enough that the lock's expiry fires and a second worker acquires the same lock and starts its own work. Without a fencing token, both workers can go on to write their results, and whichever write lands last silently wins, even if it came from the stale first worker waking up late. With a fencing token attached to the lock grant, the downstream system storing the result can reject any write that carries an older token than one it has already accepted, so the stale worker's write is rejected even though it genuinely believed it still held the lock. The token is what turns "the lock probably worked" into an actual correctness guarantee.