Lock granularity vs contention. A lock on the entire table serialises all writers. A lock per record allows parallel writes to different records but creates more lock records. Finer granularity means less contention but more coordination overhead. The right granularity is the smallest scope that prevents the conflict you care about.
TTL length vs safety window. A long TTL means the lock survives slow operations but leaves the system locked longer when a process crashes. A short TTL reduces crash recovery time but risks expiry during legitimate slow operations. There is no TTL that is always right; the correct value depends on the maximum expected operation duration.
Distributed lock vs application-level serialisation. Sometimes the correct answer is not a distributed lock at all. If work can be partitioned — each worker owns a disjoint subset of records — there is no shared state to protect and no lock is needed. Partition the work before reaching for the lock.
Lock availability vs consistency. AT1: a distributed lock enforces consistency (only one writer at a time) at the cost of availability during failure. If the lock service is unavailable, no work can proceed. A CAS-based approach degrades to retry loops rather than blocking entirely — lower consistency guarantee, higher availability under lock-service failure.