Most distributed locks are a design smell: give one thing ownership, skip the protocol

The closing installment of a four-part dev.to series on distributed locking spends its last pages arguing against the machinery it just finished explaining: after locks, leases, fencing tokens, leader election and consensus, the author's advice is to step back and ask whether the system can be redesigned so that coordination is not necessary at all ^[1][3]. That is the right conclusion, and it is worth stating plainly because the opposite reading is so tempting: study enough coordination primitives and you start to believe reliability is a function of how sophisticated your primitive is ^[2].

The cost side of the ledger is the part teams skip. Every coordination mechanism adds network communication between services, adds failure scenarios that must each be handled correctly, adds operational surface that has to be monitored, debugged and maintained, and usually adds latency, because coordination means waiting for agreement or confirmation ^[4]. The series' framing is that the most reliable systems are often not the ones with the strongest coordination but the ones that minimise coordination while still preserving correctness ^[5].

The two worked examples are unglamorous and that is the point. First, duplicate registration. The naive design acquires a distributed lock, checks whether the email exists, inserts the customer, then releases the lock ^[6]. The alternative is one line of DDL: a unique index on customer(email) ^[8]. Every instance then just attempts the insert and lets the constraint accept or reject it, with no lock, no coordination service and no lease management ^[7][9]. Counting the source's own diagrams, that is four steps down to one application operation, and two of the four steps existed only to manage the lock ^[1].

Second, concurrent updates to the same row. Two instances read an inventory record at version 8; A writes and the record becomes version 9; B's write still carries version 8, the database rejects the mismatch, and B retries from the current state ^[11][12]. No instance ever held exclusive ownership ^[11]. The author's claim for this pattern is throughput, because operations are not blocked, plus lower coordination overhead and a simple recovery model, and notes it works particularly well when conflicts are relatively rare ^[13].

What both fixes have in common is not cleverness but ownership: the invariant is enforced at the single place that owns the data, rather than negotiated in a protocol between peers who each think they might own it ^[2]. That is the test to apply before you write any lock acquisition code. If the rule you are protecting lives entirely inside one store, the store should enforce it, and the series says as much ^[10].

The honest boundary is in that same sentence. The delegation argument is scoped to cases where correctness depends entirely on the state of a single database, so it says nothing about invariants spanning two stores or a store plus an external side effect ^[3]. Those are where leases and fencing tokens still earn their keep.

What to watch, if you are holding a lock today: measure your actual conflict rate before adopting optimistic concurrency, since the source's own qualifier is that the pattern suits rare conflicts ^[13]. Watch retry behaviour under load, because a rejected write becomes application work rather than a queue behind a lock ^[12][13]. And check whether the invariant your lock defends is already expressible as a constraint, which is a schema change rather than a new dependency ^[8][9].