When single-instance is enough.

Redlock is the right tool for a specific shape of problem: coordination across machines where a lost lock is costly enough to justify fault tolerance, but not so catastrophic that only a consensus system will do. The source names four fits and four signals to reach elsewhere.

Redlock is appropriate for coordinating access to an external resource that has no concurrency control of its own; for preventing duplicate job execution in a distributed task queue; for distributed rate limiting where approximate correctness is acceptable; and for leader election among application instances. Each shares a trait: the work is coordination, the consequence of a brief overlap is tolerable or recoverable, and the operational cost of five masters is worth paying for fault tolerance a single instance cannot give.

Reach for an alternative when the shape is different. Use a consensus system — etcd or ZooKeeper — when absolute correctness is required and a lock violation cannot be tolerated. Use fencing at a linearizable resource when the storage layer can enforce a monotonic token, a stronger guarantee than any lock. Stay with single-instance Redis when its reliability is sufficient. And avoid Redlock when the operational complexity of five independent masters is not justified by the failure it prevents. That last line is the hinge: Redlock’s price is not the algorithm — it is the infrastructure.

The whole module collapses to one decision, and it is about the consequence of a lost lock, not the lock itself. A lock can always be lost — a failover, a clock jump, a process pause past the lease. What separates the right answer is what happens next.

If a lost lock causes catastrophic corruption — two writers mutate a balance, a transfer is applied twice with no record, an external system is driven into an inconsistent state it cannot recover from — then the lock is a correctness boundary, and a lock that can fail under timing assumptions is the wrong boundary. The answer is a consensus system that does not rest on bounded clocks, or a resource that enforces a fencing token, so a stale holder is rejected where the data changes.

If a lost lock causes a recoverable retry — the same work runs twice, and running it twice is safe because the operation is idempotent and a recovery path reclaims the orphaned unit — then the lock is an optimization, not a correctness boundary. Here a single-instance lease is sufficient, and the five-master cost buys a guarantee the workload does not need. A job queue lands squarely on the recoverable side, and that is the contrast EchoMQ makes concrete.

The source closes on a four-row comparison. It is the trade in one frame: Redlock buys fault tolerance with complexity, and a single instance keeps it simple at the cost of surviving a node failure.

EchoMQ takes the single-instance side, and the choice is deliberate, not a compromise. A job queue does not need absolute mutual exclusion; it needs one active worker per job in the common case and a safe recovery when that breaks. The lock is the claim lease on one Valkey. The @claim script (echo/apps/echo_mq/lib/echo_mq/jobs.ex:126, run by Jobs.claim/3 at jobs.ex:283) reads one server clock and stamps the lease — no majority of N and no second master.

The reason this is safe is the recovery path, not the lock. The EchoMQ.Consumer holds the lease for :lease_ms (default 30_000, echo/apps/echo_mq/lib/echo_mq/consumer.ex:57); on each beat it calls Jobs.reap (consumer.ex:93), which returns every expired lease in active to pending on the same server clock. The next worker re-claims the job and increments attempts; when the original worker resumes, @complete/@retry refuse its stale token with EMQSTALE … token mismatch. Because the handler is idempotent, the re-run produces the same result. A lost lease becomes a double-run the queue recovers from, not two writers corrupting a resource — exactly the move Redlock’s critics prescribe, applied where the data changes instead of at the lock.

Redlock is a real tool with a real price: five independent masters, no replication, the acquire-and-time-check protocol. The source names where it fits — external resources, duplicate-job prevention, approximate rate limiting, leader election — and where to reach past it: a consensus system when correctness is absolute, a fenced resource when the storage layer supports a token, a single instance when its reliability is sufficient. The whole module reduces to one axis: a lost lock that causes catastrophic corruption needs more than a lock; a lost lock that causes a recoverable retry needs less. EchoMQ reads the recoverable cell — @claim on one Valkey, the attempts fence, and Jobs.reap reclaiming a lapsed lease, with an idempotent handler that makes a re-run safe — and keeps one Valkey.