Distributed Lock Service

Phase 1: Requirements & Use Cases

Interviewer: "Design a distributed lock service."

Candidate: "Let me confirm scope. We're designing the OOD model for a lock service that coordinates mutual exclusion across multiple processes or nodes — something like what ZooKeeper or Redis SETNX provides. The core concern is the class design: Lock, LockManager, client API, TTL handling. We are NOT designing the replication, consensus algorithm (Paxos/Raft), or network transport — those are distributed systems concerns. Does that match?"

Interviewer: "Yes. What use cases do you need to support?"

Candidate: "The core use cases are:

1. acquire(lockName, clientId, ttl) — attempt to acquire a named lock; block or return failure if already held
2. tryAcquire(lockName, clientId, ttl) — non-blocking acquire attempt; return immediately with success/failure
3. release(lockName, clientId) — release a lock; only the holder can release
4. renew(lockName, clientId, ttl) — extend the TTL of a held lock to prevent expiry during long operations
5. TTL-based auto-expiry — locks automatically expire after their TTL to handle crashed/partitioned clients
6. isLocked(lockName) — check if a lock is currently held
7. getLockInfo(lockName) — return holder, acquisition time, TTL"

Interviewer: "What happens when a client dies while holding a lock?"

Candidate: "That's why TTL is mandatory. Every lock has a maximum lifetime. If the holder crashes, the lock expires automatically after TTL elapses. The lock service needs a background thread (or lazy-expiry on each operation) that reaps expired locks. I'll design for lazy expiry on acquire/check operations plus an optional background sweeper."

WHY:…