Problem
Multiple instances need exclusive access (cron, migration, leader). Single-node lock fails if instance dies.
coordinationestablished · low operational burden
Distributed Lock
Also known as: redlock, distributed-mutex, leader-lock, etcd-lock
Intent
Coordinate access to shared resource across distributed processes, ensuring mutual exclusion with fault tolerance.
Forces
- •Lock must survive holder crash (auto-release)
- •No single point of failure in lock service
- •Fencing: prevent stale holder from acting after lock lost
- •Performance: lock acquisition fast, low contention
Solution
✓ When to Use
- •Singleton task across multiple instances
- •Leader election for HA services
- •Coordination without message broker
✗ When Not to Use
- •High-contention hot paths (use partitioning)
- •Long-held locks (minutes+) — prefer leases
- •Team not ready for fencing discipline
Pros
- +Reliable coordination across failures
- +Auto-release on crash (TTL)
- +Fencing prevents split-brain corruption
Cons
- −Lock service = SPOF (mitigate: HA cluster)
- −Clock skew breaks TTL logic
- −Fencing requires resource cooperation
- −Performance: network round-trip per acquire
Cost Profile
Infrastructure
Low — uses existing coordination backend
Operational
Low — monitor lock contention
Cognitive
Medium — fencing, TTL tuning
Failure Modes
Clock skew: lock expires early/late
Network partition: split-brain (two holders)
No fencing: stale holder corrupts data
Lock service down: no coordination possible
Long GC pause: holder loses lock unknowingly
Real-World Examples
Alternatives
- leader-election
- partitioning
- optimistic-locking
- idempotency-key
Related Patterns
- leader-election
- distributed-lock
- fencing-token
- optimistic-locking
- etcd
Competency Domains
coordinationreliability opsdata statedistribution communicationsecurity compliance