Distributed Locking with Redis Redlock When multiple services need mutually exclusive access to a shared resource (files, counters, payments, job execution), you need a distributed lock. I recently came across this redlock algorithm by redis and it's a true distributed systems masterpiece BUT DONT USE IT FOR CONSENSUS --- A single-node Redis lock (SET key value NX PX=TTL) is fast but unsafe: Redis can crash → lock disappears Network partitions → split-brain Clients can pause → act with expired locks So Redis proposed Redlock: Use N = 5 independent Redis nodes. Client tries to acquire the lock on all nodes with a TTL. If it obtains ≥ 3/5 locks within a bounded time window → lock is considered acquired. But here’s the problem — Redlock relies on timing assumptions. To be safe, Redlock implicitly assumes: bounded clock drift bounded process pauses bounded network delays TTLs expiring “on time” In real distributed systems, none of these hold. Your process can GC-pause for seconds. Packets can be delayed for minutes (yes, this has happened at GitHub). NTP can jump the system clock forward/backwards. A Redis node can crash and lose the key before syncing. If any of these happen, Redlock can violate safety: Two clients can both think they hold the lock. This is fatal if the lock protects correctness (e.g., money movement, inventory writes). The deeper issue: Redlock has no fencing tokens. Correct distributed locking requires monotonically increasing fencing tokens: Client A acquires lock → token 33 Client B acquires lock → token 34 Downstream systems (DB, S3, job processor) must reject old tokens. Redlock returns random values — not monotonic. So you can't build correctness guarantees on top of it. TL;DR Redlock ≠ consensus Redlock ≠ safe under arbitrary delays Redlock ≠ safe under clock drift Redlock ≠ safe for correctness-critical locks Redlock is okay only for “prevent duplicate work” use cases If correctness matters → use ZooKeeper/etcd/Consul. They implement real consensus and generate fencing tokens reliably.