`for update skip locked` is the line the whole design rests on. Postgres takes the rows the claim query matched, and when another transaction already holds one it skips that row instead of waiting behind it [13]. Twenty workers can issue the same claim statement concurrently and no two of them get the same job, with no leader, no lease service and no Redis [14]. Postgres has shipped that behaviour since 9.5 in 2016, which is the basis for the author's remark that most teams buy a broker to get something their database already does [15].
Two implementation details are load-bearing rather than decorative. The claiming transaction ends as soon as the rows are marked running, and the sending happens outside it, because a transaction held open for the length of a job pins a connection and blocks vacuum [16]. And `locked_until` is a lease, so a periodic statement has to move expired leases back, or a worker that dies mid-job strands its rows in running forever [17].
The arithmetic on the diff: 1,850 plus 1,340 plus 910 is 4,100 lines of service code [1][3], against 41 lines of table plus 560 lines of worker, which is 601 [2]. That is 3,499 lines removed, about 85 percent [1]. The three responsibilities did not go anywhere. They became columns, with `run_at` doing scheduling, `attempts` and `max_attempts` doing retry, and `kind` and `payload` doing notification [10].
The dev.to writeup reports no throughput number at all: no jobs per second, no claim latency, no vacuum measurement [2]. So the line count transfers only if a few conditions hold on your side. The ready set has to stay small, because the partial index is cheap only while a few thousand ready rows sit inside a table of millions [11]. The claim statement writes to every row it takes, incrementing `attempts` and setting a lease [12], so that write volume on top of ordinary traffic has to fit one instance's autovacuum budget. And every handler has to be idempotent, since reclaiming an expired lease can re-run a job that already reached the provider [17].
The seam is the actual finding. Each service owned something nameable, namely templates and provider delivery, timing, and backoff with dead-lettering [6], and by the author's account none of them was badly built [5]. The defect lived between them: insert the order, publish the message, and a publish that fails after the commit leaves an order that nothing downstream knows about, with no exception and no alert [7]. The queued fix was an outbox table, a relay process and consumer-side dedupe, three more parts to cover one seam [9]. Eighteen months of green dashboards across three deployments [4][5] surfaced none of it, because a boundary error does not page anyone. It shows up as a customer with no receipt and a row that looks completely fine [7].
