The claim path in the sample opens with `BEGIN IMMEDIATE` before it reads a due row [11]. That is where the atomic claim in the contract actually lives [3]: the worker takes the write lock first, so two workers cannot both read the same pending job and both conclude they own it. Scheduling has the mirror property. Rows go in with `INSERT OR IGNORE` [11] against `digest_key` as the table's primary key [10], so running the scheduler twice for the same week produces one row instead of two. Neither line is remarkable on its own; together they are the guarantee, and they would look the same behind a webhook, a subscription, or a polling loop.
The lease number is where I would argue with the defaults. The example claims due work with a 60-second lease and runs on the standard library alone [9]. The demanding case in the same post is a digest that must begin within 30 seconds of a fixed cutoff, the point at which queue latency and regional failover become material [8]. A worker that dies one second after claiming leaves that job unavailable for the remaining 59 seconds, roughly twice the entire start budget [16]. Sixty seconds is a sensible number on a laptop and a poor one against a thirty-second promise. Hence the request for two figures instead of the word "fast": the maximum acceptable delay, and the maximum time an abandoned lease may block a retry [8].
On the label itself, the post's position is that "exactly once" is an application outcome rather than something to infer from a queue's name [14]. Read that the way you read a vendor benchmark table, and ask what would have to be true for the number to transfer. The condition is narrow. There are four moments to separate, eligibility computed, job committed, worker claims, downstream accepts, and a process can stop between any two of those writes; if it stops after acceptance but before the job is marked complete, retrying is the conservative move, and the retry duplicates the digest unless the downstream operation accepts the same idempotency key [4]. So the label transfers only if your mail provider deduplicates on that key. If it does not, deduplication is yours to write, and the transport has no opinion on the matter.
The sequencing is the part worth copying: write the contract before choosing a transport, starting from one durable job per active customer at the cutoff and the standing assumption that any job may be attempted more than once [18]. Everything after that is operations.
