Locks, mutexes, semaphores, monitors are usually associated with concurrent programming. But exclusive resource access is also needed in distributed environments, e.g. when using a micro-service architecture.

When having multiple instances of a service, it needs to be ensured that the action is performed only by one instance. A leader will be elected, and failure needs to be detected and dealt with. Consensus algorithm like Paxos exist. A separate locking service could be build, which is able to manage locks. The service needs a strongly consistent datastore, which holds information about the lock (who holds it, how long) and there needs to be logic to deal with failures.

• Distributed locking with Zoo-Keeper: https://dzone.com/articles/distributed-lock-using
• Hashicorp Consul: https://www.consul.io/docs/guides/semaphore.html
• Google Chubby
• Distributed locks with Redis: https://redis.io/topics/distlock
  • Not recommended when lock should be used for guarantee correctness (http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html)
• Relational database
  • Fencing tokens
  • Linearizable writes
    • Writes should appear to be instantaneous. Once a write completes, all later reads should return the value of that write or the value of a later write. Once a read returns a particular value, all later reads should return that value or the value of a later write.