For problem 1, you&#x27;d use a distributed lock to update more than one resource. A single resource could very well implement its own lock in which case you don&#x27;t need a distributed lock. But once you have more than one resource to update, you do.<p>A lock should result in linearized access (all resources updated while holding the lock should be updated in the same order based on the time when the lease was granted). A counter is enough to put the updates in order. Giving leases a unique id doesn&#x27;t do that - the network could reorder writes seen by two different resources. Fencing ensures that if the network does reorder writes, one of them fails.<p>The lock is acting sort of like a clock that ticks whenever it hands out a lease. The resources effectively update their local clock whenever they see an update with a new token from the central clock, and use this local clock to detect stale writes.<p>Note that fencing doesn&#x27;t guarantee that writes don&#x27;t happen late - all updates could be delayed by 10 seconds and it wouldn&#x27;t catch it. But it isn&#x27;t feasible to prevent this on systems with bad clocks connected by a flaky network.