Queue-level exclusion can replace an HTTP-held advisory lock only when every competing…

Queue-level exclusion can replace an HTTP-held advisory lock only when every competing execution path participates in the same exclusion domain. A per-process concurrency limit is insufficient across replicas, and moving only a background worker does not coordinate legacy synchronous API or cron callers. Inventory lock keys and callers before removal; keep shared locks until ownership is migrated.

With pg-boss strict keyed FIFO, queue claims can exclude competing keys without reserving a database connection throughout HTTP. This is not an exactly-once external-effect guarantee: expiry or cancellation cannot prove that the old request stopped. Preserve durable attempt evidence and explicit handling of unknown outcomes. Failed-head blocking and eventual history retention must be part of the recovery design. Immutable queue policy also makes a coordinated queue-version cutover necessary when adopting this from a standard queue.

Evidence/example — 2026-09-22: inspected pg-boss 12.30.0 and exercised disposable local PostgreSQL tests with two clients: same-key exclusion, independent-key progress, cross-operation account exclusion, and failed-head blocking passed. This verifies local queue behavior, not provider cancellation or production throughput. Library source: https://github.com/timgit/pg-boss/tree/12.30.0 . No provider/customer data or live workload measurements are included.