Part of the Distributed Coordination series.
Start here: What Is a Distributed Lock? (With Examples)
Opinionated default
Prefer invariant-preserving data contracts over external locks. Locks are coordination machinery plus failure surface. Invariants in storage usually survive incidents better than client-side ownership assumptions.
Many teams reach for locks because they look like a direct translation of “only one worker.” In production, that shortcut often creates hidden dependencies on lease timing, renewal health, and client behavior under pause.
Distributed locks are often the wrong abstraction
Locks coordinate entry into work, but they do not by themselves validate state transitions. If correctness depends on transition validity, state-model constraints are stronger than lock ownership.
They also expand failure surface: lock store health, TTL tuning, clock assumptions, unlock semantics, and stale resumption behavior become part of your correctness story.
Lease expiry does not stop execution. A resumed process can still act unless mutation boundaries reject stale authority.
Alternatives that are often better
- Idempotency keys: safe retries for boundary operations.
- CAS / optimistic concurrency: reject stale versions directly.
- Partition ownership: one owner per shard to avoid global contention.
- Queue serialization: ordered per-key processing without lock churn.
- Single-writer assignment: structural ownership instead of per-operation lock negotiation.
Idempotency and CAS are usually safer because they bind correctness to data transitions, not scheduler timing. Partition ownership and single-writer models reduce coordination frequency by construction, which improves both reliability and debuggability.
Queues outperform lock-heavy workflows when ordering scope is clear. You trade global lock contention for explicit per-key sequencing and bounded backpressure behavior.
Decision guide
- Duplicate work acceptable? Skip locks; use idempotency + retry budget.
- Single record race? Use CAS/version checks.
- Ordered work per key? Use keyed queues or partition workers.
- Global singleton maintenance task? Lease-backed lock can be fine.
- Correctness-critical shared mutations? If lock is used, pair with write-path validation (for example fencing/version checks).
Production story: a team replaced a global lock with partition ownership + CAS guards and removed repeated stale-owner incidents. Throughput improved because workers no longer contended on one hot coordination key.
Why this breaks in real systems
GC pauses, network delay, clock drift, and process stalls all stress lock timing assumptions. Alternatives like CAS and idempotency remain robust because they validate state directly instead of inferring safety from lease timing.
Correctness must be enforced at the write boundary. If you can do that directly, skip the lock.
What to Read Next
→ Read next: Backpressure in Distributed Systems: Stability, Correctness, and Graceful Degradation.