Architectural Breakdown & AnalysisFAANG Aligned
Distributed locks prevent race conditions when background workers attempt to execute non-idempotent operations simultaneously.
1. Redis Redlock Algorithm
- Worker requests locks from $N$ independent Redis instances with a short TTL.
- Lock is granted if acquired from a majority ($N/2 + 1$) of nodes within lock validity duration.
- Trade-off: Extremely fast, but sensitive to system clock drifts across nodes.
2. ZooKeeper / Etcd Consensus Locks
- Worker creates an Ephemeral Sequential Node in ZooKeeper.
- The worker holding the lowest sequence number owns the lock. Other workers watch the previous node for deletion.
- Trade-off: Strongly consistent (CP in CAP), immune to clock drift, but incurs higher node latency.
WARNING — Lock TTL & Fencing Tokens
Always use Fencing Tokens (monotonically increasing version numbers) to prevent a paused worker (due to GC or network delay) from writing after its lock TTL expires.
Key Architectural Comparison
| Distributed Lock System | Consensus Algorithm | Heartbeat / Expiration | Split-Brain Resilience | Performance |
|---|---|---|---|---|
| Redis (Redlock) | Independent quorum votes across 5 nodes. | Time-To-Live (TTL) auto-expiry. | Moderate (clock drift can invalidate assumptions). | Ultra-Fast (<1ms in RAM). |
| ZooKeeper | ZAB (Atomic Broadcast). | Ephemeral node deleted on session loss. | Guaranteed (Strict CP quorum). | Fast (2-5ms). |
| etcd | Raft consensus. | Lease keepalive with revision tokens. | Guaranteed (Kubernetes gold standard). | Fast (2-5ms). |