Distributed lock lease expiration can corrupt data despite proper TTL

A worker that acquires a distributed lock for a limited time (e.g., 10 seconds) may pause during its update (e.g., due to GC, CPU starvation, a frozen container, or a SIGSTOP). When the lock lease expires, another worker can acquire the same lock, complete its update, and successfully write a new value. If the first worker resumes after the lease has expired, it can still write its stale result, overwriting the newer data. This demonstrates that most distributed‑lock implementations are leases, not true mutexes, and cannot abort a delayed operation.

The flaw is not the lock service but the protected resource’s lack of a fencing token that can reject writes from an old owner. Proper implementations must verify that the lock being released is the same instance that was acquired and must enforce ordering, such as using a fencing token or compare‑and‑delete logic. The article cites the 2012 GitHub outage, where network delays caused similar lease‑expiration issues, leading to several hours of recovery work. It also describes Redis’s recommended locking pattern (SET key random‑value NX PX ttl) and the need for additional safeguards (e.g., DELEX … IFEQ) to prevent stale writes.