Part of the Distributed Coordination series.
Start here: What Is a Distributed Lock? (With Examples)
Guarantee profile summary
Redis: very common and low latency; often chosen for efficiency-oriented coordination.
ZooKeeper: coordination-first workflows with ephemeral/sequential node semantics.
etcd: linearizable consensus-backed operations with lease and transaction primitives.
All three can coordinate work. The deciding factor is the failure cost you can tolerate when ownership evidence is delayed, stale, or split across subsystems.
Choose this when:
- Redis: efficiency workload, low latency priority, duplicate work tolerable.
- ZooKeeper: coordination-first workflows and explicit election/ordering patterns.
- etcd: correctness-critical coordination where linearizability is a hard requirement.
For interview-style shorthand: choose Redis when waste is acceptable, choose ZooKeeper/etcd when ownership ambiguity is unacceptable. The decision is about failure impact, not preference.
Why Redis locks fail for correctness
Redis lock patterns generally rely on timing assumptions: TTL sizing, renewal cadence, and release ordering. Under long GC pauses, network delay, or clock skew, stale holders can still run and attempt writes after ownership moved.
Without fencing token enforcement at the write boundary, Redis acquisition success does not prevent stale-writer corruption. This is why Redis is often excellent for efficiency control but risky as a sole correctness mechanism.
Why consensus systems are preferred for correctness
Consensus-backed systems provide clearer authority semantics under partition and failover. Linearizable operations give a stronger basis for “who owns now,” and transaction primitives reduce race windows during acquire/release transitions.
That does not eliminate stale execution in clients, but it narrows ambiguity in coordination state and makes fencing-based correctness designs easier to reason about.
What people often get wrong
- Choosing by popularity instead of failure impact.
- Choosing Redis for correctness workloads without storage-side stale-writer rejection.
- Treating lock acquisition as proof of downstream write safety.
- Ignoring owner-checked release semantics.
Where fencing still matters
Regardless of backend, stale-owner risk remains unless the mutation boundary rejects stale authority. See Fencing Tokens Explained.
Common mistake: “Choosing Redis for correctness workloads” and assuming the lock API itself provides write safety.
Why this breaks in real systems
GC pauses delay renewal, network delay causes duplicate ownership perception, clock drift narrows safe TTL assumptions, and process stalls let old workers resume late. Coordination and mutation boundaries drift apart unless explicitly rejoined by token checks.
Production story: a cache-backed lock looked healthy at p50 latency, but p99 pauses during deploy caused stale owners to continue writes. The incident was not lock unavailability; it was stale authority accepted downstream.
References
- Redis. Distributed locks with Redis. redis.io
- Apache ZooKeeper. Recipes and solutions. zookeeper.apache.org
- etcd. How to create locks. etcd.io
What to Read Next
→ Read next: When Not to Use a Distributed Lock.