Redlock

Redlock acquires a lock on a majority of N independent Redis instances within a bounded time, treating the lock as held only if the majority succeeded and enough validity remains.

It is worth knowing chiefly for the debate it produced. Martin Kleppmann's critique argues the algorithm relies on bounded clock drift and bounded pauses, neither of which holds: a process that garbage-collects for longer than the lock's validity resumes believing it holds a lock that has expired and been granted to someone else. Salvatore Sanfilippo, Redis's author, responded defending the assumptions for the intended use cases.

The transferable conclusion, which both sides broadly accept, is the distinction between two purposes for a lock:

Efficiency — avoiding duplicate work, where an occasional double execution is merely wasteful. A lease-based lock is fine.

Correctness — where two holders would corrupt data. Here a lock alone is never sufficient; you need fencing tokens enforced by the resource, or the operation must be idempotent so a duplicate is harmless.

If you cannot name which of the two you are doing, you are probably assuming correctness and building efficiency.