Thanks to Martin for analyzing Redlock, I looked forward to an analysis. I don&#x27;t agree with the two main arguments of the analysis. TLDR: I think the unique random token of Redlock is enough for Check &amp; Set when the lock holder work materializes into a database write (also note that it requires a linearizable database, to check token_A_ID &gt; token_B_ID in the Martin proposed solution), and I think the system model is very real world (AFAIK the algorithm is not dependent on bounded network delays, I think there is an issue in the analysis, details in my blog post so other people can evaluate), and that the fact different processes can count relative time, without any absolute clock, with a bound error (like, 10%) is absolutely credible. However, I&#x27;m analyzing the analysis in depth right now and writing a blog post with the details to be posted tomorrow. Also note that usually when you need a distributed lock, it&#x27;s because you have no sane way to handle race conditions, otherwise you can do with some weaker and&#x2F;or optimistic locking form to start with.