The two concurrency primitives you actually used

Strip away the vocabulary and your two projects control concurrency with exactly two primitives. Own them at the whiteboard level.

Primitive 1: the CAS update (compare-and-swap as SQL)

-- zoth: state machine transition
UPDATE access_requests
SET status = $3                     -- or: status='ACTIVE', expires_at=$4
WHERE id = $1 AND status = $2       -- expected-value guard

RowsAffected == 1 → you won the transition. 0 → someone else changed it first → map to ErrConflict → 409. In zoth this is UpdateStatusConditional / ActivateConditional (internal/repositories/postgres/access_request.go) and the entire JIT state machine runs on it. Traverse equivalents: ring closure (updateMany where closedAt:null, count===1 is the claim), set-once topic (where topic IS NULL), the StreakDay upsert.

What it gives you: lock-free multi-replica safety (any number of processes can run the expiry loop; the row decides), no retry storms (losers get a clean semantic result), and an audit trail (each successful transition is a discrete event).

What it can't give you: multi-row invariants (Day 31's escalation ladder), and duration semantics — it's instantaneous, not a lease. Which is why you also need…

Primitive 2: the claim (lease via SKIP LOCKED)

-- zoth: outbox relay
SELECT id FROM outbox_events
WHERE published_at IS NULL
ORDER BY created_at LIMIT $1
FOR UPDATE SKIP LOCKED;
-- then: UPDATE outbox_events SET published_at = NOW() WHERE id = ANY($claimed)

-- traverse: notification drain
UPDATE notification_delivery nd
SET attempts = attempts + 1,
    next_attempt_at = NOW() + INTERVAL '120 seconds'   -- the lease
FROM (
  SELECT id FROM notification_delivery
  WHERE status='pending' AND next_attempt_at <= NOW()
  ORDER BY next_attempt_at LIMIT $n
  FOR UPDATE SKIP LOCKED
) claimed
WHERE nd.id = claimed.id;

Two different flavors, one idea: the table row is the work item, the row lock (or a forward-dated lease) is the claim. Zoth's relay claims via transaction-scoped row locks (released on commit — if the process dies mid-batch, rows return to the pool automatically). Traverse's drain claims via a forward lease (next_attempt_at + 120 s) persisted in the row — a dead worker needs no cleanup; the lease expires and the next drain retries. Both patterns are production-grade Postgres work queues — and "Postgres SKIP LOCKED work queue" is a named topic in your study list; you've implemented it twice.

Why the lease version exists at all: the drain's work happens after the claim transaction commits (sending via APNs/FCM takes seconds and must not hold row locks). You can't hold a lock across external I/O — so the claim must be time-based. The forward lease means "I own this until 12:02; if I die, it's yours at 12:02." Reclaiming a stuck-but-alive worker's rows is impossible with pure leases (it will double-send) — bounded by idempotent sends? Push notification double-sends are acceptable (the coalescing and apns-collapse-id reduce the user-visible impact); if they weren't, you'd add fencing.

Where each appears (the full map)

The narrative: "Between conditional updates and SKIP LOCKED claims, I've never needed a distributed lock, a lock service, or a leader — the database is the coordinator. That works because every unit of work is a row, and Postgres gives rows atomic transitions. The day work items stop being rows is the day I'd reach for ZooKeeper/Redlock — and I'd reach reluctantly."