Sessions rather than bare TTLs. The client maintains a heartbeat; the service tracks liveness rather than only wall-clock expiry. In ZooKeeper an ephemeral znode vanishes when the session ends, which means a crashed client's lock is released promptly rather than after a full TTL — better detection and a shorter unavailable window than a TTL alone can give you.

A monotonic token, for free. ZooKeeper's zxid (and the sequence number on a sequential znode) and etcd's revision are already monotonically increasing, cluster-wide. You do not have to invent a fencing token; the service hands you one. This is the single strongest argument for using a real lock service over a Redis key, because it makes the correct pattern the easy one.

The canonical etcd shape:

Two details in that snippet matter as much as the acquire. The transaction is a compare-and-swap, not a read-then-write, for the reason Module P-16 gave about claims. And the lost handler exists because a client that learns its session ended must stop working immediately rather than finishing — the one thing a holder can do about the expiry problem, even though it is not a guarantee.

One more classic: the herd effect. If a thousand waiters all watch the lock key, releasing it wakes a thousand clients who all attempt to acquire, and 999 fail. The ZooKeeper recipe is for each waiter to create a sequential node and watch only its immediate predecessor, so a release wakes exactly one client. It is Module P-12's thundering herd in coordination clothing, and the fix has the same shape: do not broadcast an event that only one recipient can act on.

---

The Implementation Details That Become Incidents

A lock without a TTL is a deadlock waiting for a crash. Same lesson as Module P-19's job lease and Module P-16's idempotency claim: a finally block does not run when a process is killed, so every ownership must expire on its own. A permanent lock on a nightly job is discovered a week later, when someone asks why the reports stopped.

Releasing must verify ownership, or you release someone else's lock.

The broken version produces a lovely cascading failure: A's lease expires, B acquires, A finishes and deletes B's lock, C acquires while B is still working, and now the lock is meaningless for everyone. It is worth checking every lock helper you own for this, because the two-line version is what people write first.

A renewal after expiry is not a renewal. Extending a lease must be conditional on still holding it — the same compare-and-set — and if the conditional extend fails, the correct action is to abandon the work, not to re-acquire and continue as though nothing happened. Re-acquisition means someone else may have already started and partially completed the work.

Measure the lease locally with a monotonic clock. You acquired a 10-second lease; how long have you held it? Not "what does the server's clock say" — Module A-1's rule applies, so use process.hrtime.bigint() and treat the lease as expired well before its nominal end, because network time to the service, your own scheduling delays, and clock error all eat into it. A generous safety margin is the only defence available to the holder.

Most implementations are not reentrant, and lock ordering still matters. Acquiring the same lock twice in a call stack will deadlock against yourself. And a system taking two locks in inconsistent orders will deadlock, distributed-systems-scale, with no detector — a database gives you 40P01 deadlock detection, and etcd does not.

Granularity is a real trade. One coarse lock is simple and serialises everything (a throughput ceiling of one). Per-entity locks give concurrency and multiply the number of things that can be held, leaked, or acquired out of order. Prefer the finest granularity that still protects the invariant, and prefer no lock at all — which is the next section.

---

Design the Lock Away

Most distributed locks in production exist because a lock was the first mechanism that came to mind, not because coordination was required. Six alternatives, roughly in order of how often they apply:

1. Make the operation idempotent, and concurrency stops mattering. If running it twice is harmless, you do not need to prevent running it twice (Module P-16). This dissolves more locks than every other technique combined.

2. Use a uniqueness constraint as the lock. The database is already a correct, consensus-backed, crash-safe lock manager:

One statement, no TTL to tune, no release to get wrong, and it is transactional. Module P-19's dedupe_key on a scheduled slot is this pattern.

3. Compare-and-set on a version column — optimistic concurrency. Rather than locking a row while you think, read it, compute, and write conditionally on the version you read. Losing means retrying, not blocking, and no lock is held across a network call. This is the mechanism behind Module P-24's state transitions and it composes with fencing naturally, because the version is a fence.

4. Partition the work so a single writer exists by construction. The strongest technique in the list. Assign shards or keys to workers — Kafka's consumer group protocol (Module P-15), consistent hashing (Module P-7), a shard-assignment table — so that only one worker is ever responsible for a given key. There is nothing to lock because there is no contention. This is why Kafka needs no per-message locks and why "one consumer per partition" is an architecture rather than a coincidence.

5. Serialise through a queue keyed per entity. SQS FIFO message groups, or a Kafka partition keyed on the entity ID, guarantee that operations on one entity are processed one at a time by one consumer. You get mutual exclusion as a property of the transport.

6. Use the database's own locks when everyone talks to one database. A "distributed" lock between five app instances that all connect to the same Postgres is not distributed — it is a row lock or an advisory lock, and it is transactionally correct in a way no external lock service can be, because the lock and the data commit together.

And when the goal is a singleton task rather than per-item exclusivity, elect a leader once (etcd, or an advisory lock) and let that instance own the task, instead of taking a lock per item.

Why this matters in production: lock bugs are among the worst to diagnose because they are timing-dependent, low-frequency, and leave no error. The symptoms are two workers having processed the same job, a counter that is occasionally wrong, a duplicated outbound email, or a nightly job that has silently not run for eleven days because a killed process left a lock behind. None of these produce a stack trace, none reproduce under test, and all of them are found by a human noticing an inconsistency. Which is the strongest argument for the sections above: a design where the lock is unnecessary has no such failure mode, and a fenced resource turns the failure into a loud rejection instead of a quiet corruption.

---

Where This Shows Up in Your Stack

• PostgreSQL: advisory locks are excellent within a single database — pg_try_advisory_xact_lock for transaction scope (auto-released at commit, which is what you almost always want) and pg_advisory_lock for session scope. The pooler hazard is severe: with PgBouncer in transaction pooling mode, a session-scoped advisory lock stays attached to a server connection that is then handed to a different client, so locks leak between unrelated requests and can be released by someone else entirely. Use transaction-scoped locks with a pooler, always. SELECT … FOR UPDATE SKIP LOCKED is the lock-free alternative for work distribution (Module P-19) and is usually the better answer than locking. And row locks plus a version column give you both fencing and transactionality in one mechanism.
• Redis: SET key token NX PX 10000 is the correct acquire, and release must be the Lua compare-and-delete — a bare DEL deletes whoever's lock is currently there. Remember that Redis failover is not consensus-safe (Module A-1), so an acknowledged lock can be lost on promotion. Use it for efficiency locks and never as the sole mechanism for a correctness lock. Redlock adds complexity that does not change that classification.
• etcd / ZooKeeper: the right choice for leader election and for correctness-adjacent coordination, because they give consensus-backed grants, session-based liveness rather than bare TTLs, and a monotonic revision or zxid you can use directly as a fencing token. Use the predecessor-watch recipe to avoid the herd. Handle session loss by stopping work, not by re-acquiring.
• Kafka: the best illustration of designing the lock away. Partition assignment means exactly one consumer owns a partition, so per-key mutual exclusion is structural. And the leader epoch is a fencing token in production use: a zombie leader's requests carry a stale epoch and are rejected by followers, which is precisely the mechanism this module argues for.
• Node.js: an in-process async-mutex coordinates within one event loop and does nothing across instances — and single-threadedness gives no protection whatsoever between two pods. Also beware that a long synchronous operation blocks your lease renewal timer, so the very work you are protecting can cause your lease to lapse; that is an argument for worker_threads or chunking (Module P-19).

---

Summary

• A distributed lock is a lease, not a mutex. The lock service can only detect liveness with a timeout, so the lease can expire while the holder is still working, and the holder cannot tell a 0.2-second pause from a 40-second one.
• No lock with a timeout can guarantee mutual exclusion. A GC pause, VM steal, paused container or 30-second DNS timeout lets the holder wake past its expiry and write alongside the new holder, with every component behaving correctly and no error raised anywhere. Longer leases trade a rarer window for slower recovery from real failures.
• The fencing token is the actual safety mechanism: a monotonically increasing number issued with the grant, carried into every operation, with the resource rejecting anything lower than the highest it has seen. The overlap still occurs; it becomes harmless, and the stale writer gets a visible error instead of causing silent corruption.
• Fencing requires the resource to participate, which is why most distributed locks are unsafe. You can fence your own database rows, a service you control, Kafka's leader epoch, and object storage with conditional writes. You cannot fence a third-party payment API, an email provider, or any irreversible external effect — for those, the answer is idempotency or reconciliation (Module P-16), not a lock.
• Redlock's problems are structural: it uses timing assumptions to guarantee safety, provides no fencing token, and a restarted node forgets it granted a lock. If you need efficiency, one Redis instance suffices; if you need correctness, Redlock does not provide it — so the added complexity buys nothing you needed.
• Classify every lock as efficiency or correctness. An efficiency lock prevents wasted work and a single SET NX EX is fine. For a correctness lock, a lock is not sufficient at all — use fencing, idempotency, or a single-writer design. Mistaking one for the other produces bugs that appear quarterly and never reproduce.
• Real lock services give three things a Redis key cannot: consensus-backed grants that survive a restart, sessions with heartbeats so a dead client's lock is released promptly rather than after a full TTL, and a monotonic revision or zxid that is your fencing token — which makes the correct pattern the easy one.
• The implementation details that become incidents: a lock without a TTL deadlocks on a crash; a bare DEL release deletes whoever's lock is present and cascades into the lock meaning nothing for everyone; a renewal must be conditional on still holding it, and a failed renewal means abandon the work rather than re-acquire; measure the lease locally with a monotonic clock and a generous margin; most locks are not reentrant, and inconsistent lock ordering deadlocks with no detector.
• Watch only your predecessor, not the lock key, or releasing wakes a thousand clients so that one can proceed.
• Design the lock away, in roughly this order: make the operation idempotent so concurrency stops mattering; use a uniqueness constraint as the claim; compare-and-set on a version column so nothing is held across a network call; partition the work so a single writer exists by construction (the strongest technique — this is why Kafka needs no per-message locks); serialise through a queue keyed per entity; and use the database's own locks when every participant talks to one database, because then the lock and the data commit together. When you need a singleton task, elect one leader rather than taking a lock per item.
• With a pooler, use transaction-scoped advisory locks only. A session-scoped lock under PgBouncer transaction pooling stays with a server connection that gets handed to another client, so locks leak between unrelated requests and can be released by someone else.
• Lock bugs leave no stack trace. Two workers processing one job, an occasionally wrong counter, a nightly job silently not run for eleven days — all found by a human noticing an inconsistency, which is the strongest argument for designs that need no lock and for fences that turn corruption into a loud rejection.

The next module, Distributed Transactions, takes the same problem up a level. This module asked how to stop two actors touching one resource; A-3 asks how to make several resources change together when there is no single transaction to hold them — two-phase commit and why its blocking problem is fatal, sagas with compensating actions, and the question sagas are usually taught without: what you do when the compensation itself cannot succeed because the email has already gone out.

---