Like anything, it depends on what you&#x27;re using it for. I wouldn&#x27;t put a distributed lock into some massively high volume request path, or where absolute availability is required, but it&#x27;s perfectly fine for some scenarios.<p>As Martin points out though, many (most?) distributed lock implementations are or can be broken in various ways. He hints at one of the fundamental problems - consensus. Many distributed lock implementations fail simply because they cannot achieve reliable consensus, or don&#x27;t even try to.<p>That said, distributed locks can be safe and handle reasonably high throughput. The Atomix distributed lock is one example:<p><a href="http:&#x2F;&#x2F;atomix.io&#x2F;atomix&#x2F;" rel="nofollow">http:&#x2F;&#x2F;atomix.io&#x2F;atomix&#x2F;</a><p><a href="http:&#x2F;&#x2F;atomix.io&#x2F;atomix&#x2F;docs&#x2F;coordination&#x2F;#distributedlock" rel="nofollow">http:&#x2F;&#x2F;atomix.io&#x2F;atomix&#x2F;docs&#x2F;coordination&#x2F;#distributedlock</a><p>Since consensus requires quorum and quorum requires availability, there is a risk that your ability to obtain a lock or learn about lock related events could be effected by availability, but at least in the case of Atomix, the system is fairly resilient with auto-failovers to passive or inactive nodes as needed (as compared to, say, a ZooKeeper based lock).