Design a distributed lock service that lets many application processes across a fleet coordinate exclusive access to a shared resource — a partitioned job, a leader role, a row about to be mutated. A client acquires a named lock, does its work, then releases; while it holds the lock, no other client may hold the same name. The whole difficulty is that clients live on separate machines that can pause, crash, or get network-partitioned from your service at any instant, and the resource they guard (a database, an object store, a queue) is a system you do not control.

Operating context. The service is an internal platform primitive used by hundreds of backend services. Expect on the order of 50,000 lock acquire/release operations per second across roughly 2 million distinct lock names, with the working set of currently-held locks in the low hundreds of thousands. Most locks are held briefly (tens of milliseconds to a few seconds), but some guard long jobs running for minutes. Callers want acquire p99 under 20 ms in-region. A held lock must never be simultaneously granted to two clients, even when a holder freezes on a long GC pause or its host is partitioned away and presumed dead.

Out of scope. The application logic each lock guards, the client SDK's retry/backoff ergonomics, authn/authz of callers, multi-tenant billing/quotas, and cross-region active-active replication of the lock state (assume a single region with in-region redundancy). Assume separate teams own those.

What to produce. A high-level architecture covering: the acquire / renew / release request paths and the lock's state; where lock state is stored and how you replicate it for durability and availability (single store with a consensus-replicated log, versus a quorum across independent nodes — pick one and defend it); how a lock is leased with a TTL so a dead holder's lock is eventually reclaimed, and how a live holder renews before expiry; the fencing-token scheme that lets the guarded resource reject a write from a holder whose lease already expired; and the behavior under a holder crash, a holder GC-pause longer than the TTL, and a network partition between client and service. Sketch the components and the request flow; we probe the safety-versus-liveness trade-offs in checkpoints.