Loading today’s stories
Build1 distinct publisher3 min readPublished
You cannot commit a database row and an SMS carrier together, so the workable shape is one durable intent per channel, a leased worker, and a dedup key every retry reuses unchanged. The poller stays, with a smaller job.
The Engineer · Build desk
build
Buy transactional email on recovery controls, not send price1 distinct publisher
build
SPF and DMARC records that pass every free checker and stop nothing1 distinct publisher
build
Judge transactional email on retries and DKIM alignment, not open rates1 distinct publisher
build
Fuse ranks, not scores: a retrieval contract that refuses to guess in code review1 distinct publisher
Compiled by The EngineerSomething wrong?How this is made
Trace the case that decides the design. Worker A holds the lease on delivery `evt-42:recipient-7:email`, submits it, then terminates without a conclusive response and without changing the row [14]. The remote side may have accepted the message [13]. The application cannot infer acceptance from a timeout [13], so it holds one ambiguous observation covering two different states of the world.
At that point the options come down to three moves. Marking the row successful risks losing the notification [13]. Creating a fresh message risks a duplicate [13]. Resubmitting under the original delivery identity gives a provider that supports idempotent submission a chance to collapse the retry [13]. That third move puts the deduplication on someone else's server, which is a reasonable place for it, provided you read that provider's docs rather than your own architecture diagram. Where the capability is absent, dev.to's write-up says the system stays at-least-once, must tolerate the occasional duplicate, and you should be honest about it [13].
The shape of the key carries the argument. `evt-42:recipient-7:email` is event, recipient, channel [14]. Channel is in there because a single event produces several intents, and email and SMS differ in payload, consent rules, retry policy and terminal outcomes [3]. One stable identity per channel delivery, reused verbatim by every retry, is the third of the four invariants the piece says must be testable [12].
Batch sizing has a similar constraint hiding in it. The guidance is to start with a batch that fits comfortably inside the queue visibility or lease interval, measure the age of the oldest due item rather than average throughput, and raise the batch only once p95 processing time leaves a wide renewal margin [10]. Rearranged, that is batch size no greater than lease interval divided by p95 per-item time, minus margin [2]. The governor on throughput is your own recovery interval. Exceed it and rows get re-claimed while still in flight, which lands you back on the duplicate path.
The row itself is deliberately thin: seven named fields, and the rendered message is not among them unless audit or legal requirements demand it [1][5]. Template version is recorded instead, because silently changing the content of an already queued transactional message is its own hazard [5].
Which leaves cron. Publishing only row IDs to the queue, plus lease expiry recovery by another worker, covers the normal path [6], so the poller's remaining scope is due rows that were never published and rows whose lease ran out [3]. It stays on the payroll, just with a smaller job than before.
The author declines to name the right renewal margin, on the grounds that rate-limit behaviour and latency distributions are deployment facts rather than standards, and that production telemetry should settle it [11]. Which means you pay for that number in production measurement, not in this document.
Ranked by verification strength, evidence, and original report placement.
The provider call is the ambiguous boundary: after a lost connection the application cannot infer acceptance from the timeout, marking the row successful risks losing the notification, immediately creating a fresh message risks a duplicate, and reusing the original delivery identity gives a provider that supports idempotent submission a chance to collapse the retry; without that capability the system remains at-least-once and must tolerate an occasional duplicate, and the piece says to be honest about it.
Worked example: worker A owns the lease and submits delivery evt-42:recipient-7:email; the remote side may accept it, but A receives no conclusive response and terminates without changing the row, after which the lease expires.
Recommended design: put each event into a durable notification outbox, let a queue worker claim small batches, use cron polling only as a recovery trigger, and make every delivery attempt idempotent before tuning email or SMS throughput.
Exactly-once delivery is not a property a normal application can promise across its database, a queue, an email service, mobile networks and a recipient's handset; the narrower promise is one durable intent, controlled retries, and one stable idempotency identity per channel delivery.
The event and its notification intents are written in the same database transaction; one event may create several intents because email and SMS have different payloads, consent rules, retry policies and terminal outcomes.
The outbox row should carry an immutable event ID, recipient ID, channel, template version, locale, scheduled time and a deduplication key.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 28, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Inspectable reasoning, single voice
All of it rests on one dev.to post, and the author's argument is the only credential on offer. That argument is checkable in the way engineering prose can be — you can follow why a random request ID minted inside send() defeats deduplication, and why a timeout cannot be read as acceptance — but nothing outside the piece corroborates it. The single external anchor, RFC 6376 for DKIM, supports a closing aside about email authentication rather than the outbox design itself.
No running system shown
Nobody is reported to have built this. There is no repository, no queue depth, no duplicate rate, not even an anecdote about the OTP that went out twice. The one figure a reader would most want — how much renewal margin a particular provider's latency tail demands — is handed back to them as something only their own telemetry can answer, which is candid but leaves the adoption column empty.
Ceiling set below the pattern's reputation
The rhetoric runs cooler than the subject usually does. Exactly-once is refused outright, at-least-once with an occasional duplicate is named as the honest outcome, and the tuning section ends in 'I'm not sure'. Mildly negative rather than neutral because the piece undersells how settled its central move already is: committing the event and its notification intents in one transaction is ordinary practice, presented here as though it still needed arguing.
Nothing on sale
No email or SMS vendor is named, never mind recommended, and the provider feature the design leans on — idempotent submission — is treated as a conditional the reader must go and verify rather than a capability to go and buy. What remains is the ordinary pull of a developer platform, where a tidy, confident architecture post earns followers; enough to explain the assured tone, not enough to bend the technical advice.
Sure of the logic, unsure of the numbers
Two different confidences are tangled here and only one is high. We are confident about what the story says and that its internal chain holds — the invariants are literally written as tests, so misreading them is hard. We are not confident that the lease intervals, batch sizes and p95 assumptions survive contact with a real provider, because no one in this story has tried.