A distributed system uses indefinite (non-expiring) locks. A client acquires a lock on a shared resource, then crashes immediately — before releasing the lock. What happens to other clients waiting for that lock?
AThe lock manager detects the crash via heartbeat and automatically releases the lock within seconds.
BThe lock remains held indefinitely, blocking all other clients until a human operator manually intervenes to release it.
COther clients automatically acquire the lock after a standard TCP timeout period when the connection drops.
DThe lock is released by the operating system when the crashed process's file descriptors are closed.
This is the fundamental problem that motivates lease-based locking. An indefinite lock has no mechanism for automatic release if the holder disappears. Failure detection in distributed systems is inherently uncertain — the lock manager cannot reliably distinguish a crashed client from a very slow one. Without an expiration mechanism, the lock manager has no basis to release the lock, and no other client can proceed until the lock is explicitly released. In production systems, this kind of stuck lock has caused extended outages requiring manual intervention.
Question 2 Multiple Choice
A client acquires a distributed lease with a 10-second expiration, begins work on a shared resource, and the work takes 15 seconds. The client never explicitly renews the lease. What is the likely outcome?
AThe work completes safely; leases only affect lock acquisition and do not interfere with active operations.
BAfter 10 seconds, another client may acquire the lease and begin modifying the same resource, creating a race condition with the first client's ongoing writes.
CThe lock manager pauses other clients until the original client finishes, then releases the lease automatically.
DThe client automatically receives a 5-second extension when its work duration approaches the lease limit.
Lease expiration is unconditional — the lease manager does not know or care whether the holder is still doing useful work. After 10 seconds, the lease is available to any requesting client. If the first client is still writing at second 12 while a second client acquires the lease at second 11 and starts writing at second 12, both clients are now modifying the resource simultaneously, violating mutual exclusion. This is the key tradeoff of lease-based locking: it solves the 'crashed holder' problem but introduces a new risk if work exceeds the lease duration. Correct use requires either short-lived operations or an explicit renewal protocol.
Question 3 True / False
Lease-based locks prevent a crashed client from blocking other clients indefinitely, because the lease expires automatically whether or not the holder is still alive.
TTrue
FFalse
Answer: True
This is exactly the core benefit of leases. Unlike indefinite locks, a lease has a built-in expiration time. When the timer fires — regardless of the holder's state — the lock becomes available again. The system does not need to detect that the client crashed, determine the cause of failure, or wait for any timeout from the network layer. The lease's temporal bound makes failure handling implicit: no special recovery logic is required. This greatly simplifies the lock manager and eliminates the category of 'locks stuck forever due to holder failure.'
Question 4 True / False
Consensus-based distributed locks (built on Paxos or Raft) are generally preferable to lease-based locks because they provide stronger guarantees at no additional cost.
TTrue
FFalse
Answer: False
Consensus-based locks provide stronger consistency guarantees — a majority quorum must agree on each lock grant, ensuring consistency even across server failures. But this comes at real cost: each lock operation requires multiple network round trips to achieve consensus, significantly increasing latency compared to a simple lease from a single lock manager. Consensus clusters also require operational overhead: running 3 or 5 servers, handling leader elections, managing replication lag. For systems where lock granularity is coarse and high latency is acceptable, consensus-based locks are worth it. For fine-grained locking or latency-sensitive paths, the overhead is prohibitive. Engineering is always about tradeoffs.
Question 5 Short Answer
Why does a lease-based lock introduce a potential race condition that a simple indefinite lock does not, and what tradeoff does this represent?
Think about your answer, then reveal below.
Model answer: With an indefinite lock, only one holder exists at a time — the lock is never granted to a second client until the first explicitly releases it (or dies and is detected). With a lease, the lock is automatically re-granted when the lease expires, even if the original holder is still alive and working. If the holder's work exceeds the lease duration, a second client can acquire the lease while the first is still operating — two clients now hold the lock simultaneously, violating mutual exclusion. The tradeoff is: indefinite locks eliminate this race but create permanent blocking when a holder crashes; leases bound the blocking duration but create a time-window race condition that requires careful lease duration management and renewal protocols to handle.
The lease is an engineering compromise between two bad failure modes: (1) indefinite blocking from holder crashes (the problem with no-expiry locks) and (2) split-brain concurrent access (the new risk leases introduce). The right lease duration depends on the expected operation time and the cost of concurrent access violations. Systems that are sensitive to the race condition often require clients to stop operating before their lease expires, re-verify lock ownership before each write, or use fencing tokens — sequence numbers that allow storage systems to reject operations from clients whose leases have expired.