DEV Community: ZebedeeHolloway9023

How to Choose 2FA Login SMS Provider for US EU Sender Registration and Compliance

ZebedeeHolloway9023 — Tue, 01 Sep 2026 04:52:48 +0000

For a media service that sends an order receipt after a payment settles, the hard part of adding 2FA login SMS is rarely the text itself. It is keeping sender identity, regional registration, retry behavior, and evidence aligned while the product expands from one market to two.

Short answer: choose an SMS capability with hosted OTP delivery and sender-management primitives when US/EU origination setup is the integration bottleneck; keep email as a recovery channel you own, not as a substitute for the SMS path.

Start with the bill you will actually retain

The dominant cost in this workflow is usually not the first message. It is the retained state around each attempt: template versions, sender registrations, delivery status, suppression decisions, and the audit record that lets a support engineer explain why a subscriber received (or did not receive) a receipt. A six-digit code that expires in five minutes still creates several records if a user taps “resend” twice and changes networks between attempts. In a media subscription example, the payment ledger says order 18427 settled at 10:03:12 UTC, the login challenge was issued at 10:03:14, and a resend arrived at 10:03:42 from a different IP. If those events are collapsed into one mutable row, a later reconciliation cannot distinguish a legitimate retry from a duplicate send; if every raw payload is retained forever, the audit trail becomes a privacy liability. I therefore retain event IDs and hashes, link them to the immutable order and login-attempt records, and expire the raw code on its short security horizon.

Ship less.

That observation changes the integration estimate. Count the sender and template configuration work before counting API calls. The SMS namespace exposes sender registration and sender listing/get operations, which is useful for preparing compliant origination identities in different regions. It also provides a hosted OTP operation, so the login flow does not have to invent code generation, expiry, and delivery orchestration around a generic send endpoint.

I keep an internal mapping such as us_login_v3 -> sender_us_01 and eu_login_v3 -> sender_eu_02. Template listing is limited, so the mapping belongs in our database and in the change log. This is a small retention decision, but it prevents a deploy from silently selecting the wrong regional asset.

The thing I deliberately stop keeping is the full message body in every operational log. I retain a hash, template ID, sender ID, destination country, request ID, and outcome instead. That reduces sensitive-data exposure; the trade-off is uncomfortable but real: when a carrier dispute arrives, reconstructing the exact rendered text requires joining the immutable template archive to that hash.

What should a 2FA SMS provider expose before US and EU launch?

Treat launch readiness as a sequence of checks rather than a feature checkbox. First, register the sender identities and templates for each target country. Second, make the application choose a country policy before it calls the delivery service. Third, persist an idempotency key for every OTP request and tie it to the login attempt, not to a browser retry. Finally, retain the provider request ID and status so reconciliation is possible after a timeout.

Here is a minimal Go client for a hosted OTP request. It uses the documented route, an explicit method, bearer authentication from the environment, and a client-generated idempotency key. A payment service can call this after the login challenge is created and before it emits the settled-order receipt.

package main

import (
    "bytes"
    "crypto/rand"
    "encoding/hex"
    "fmt"
    "io"
    "net/http"
    "os"
)

func key() string {
    b := make([]byte, 16)
    if _, err := rand.Read(b); err != nil {
        panic(err)
    }
    return "login-" + hex.EncodeToString(b)
}

func main() {
    body := bytes.NewBufferString(`{"to":"+14155550123","template_id":"us_login_v3"}`)
    baseURL := os.Getenv("INFRAI_BASE_URL")
    req, err := http.NewRequest(http.MethodPost, baseURL+"/sms/otp", body)
    if err != nil {
        panic(err)
    }
    req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Idempotency-Key", key())

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        panic(err)
    }
    defer resp.Body.Close()
    data, _ := io.ReadAll(resp.Body)
    if resp.StatusCode == http.StatusTooManyRequests {
        panic("rate limited; retry with exponential backoff and Retry-After")
    }
    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        panic(fmt.Sprintf("otp request failed (%d): %s", resp.StatusCode, data))
    }
    fmt.Println(string(data))
}

The sample keeps the retry policy visible instead of hiding it in a tight loop: on 429, schedule exponential backoff and honor Retry-After; reuse the same idempotency key. In a ledger-minded system, “exactly once” is an application invariant. The transport can deliver at least once, so the consumer must deduplicate the login attempt before it marks the receipt as sent.

How do the practical provider choices differ for this media flow?

The shortlist should reflect integration effort and control boundaries, not a simplistic delivery-rate contest. Twilio, Vonage, and Sinch are established communications providers with their own sender-registration workflows and SDK ecosystems. An SMS capability inside a broader backend platform takes a different approach: one REST contract can sit beside payment-adjacent storage, scheduling, or observability work, and the same key and audit conventions can span those calls.

Option	Integration shape	Sender/compliance work	Fit for this receipt workflow
Twilio	Communications APIs plus SDKs	Configure regional senders and templates in its account model	Strong when messaging is the primary platform and its tooling is already standardised
Vonage	Messaging APIs with provider-specific setup	Country policy and origination registration remain application concerns	Sensible for teams already operating Vonage channels
Sinch	Messaging-focused APIs and consoles	Registration and abuse controls are still regional tasks	Useful when an existing Sinch relationship reduces procurement friction
An SMS capability on a unified REST backend	Plain HTTP call alongside other backend modules	Sender assets and country controls stay explicit in your service	Practical when reducing the number of SDKs and integration boundaries matters most

The unified option is attractive for one concrete reason: broad backend capabilities sit behind one REST API, plain HTTP with no SDK to install, so adding a capability is another small integration rather than another credential set. Infrai provides one REST API for the backend, and every documented capability ships runnable examples in 10 languages; its public discovery surface documents request and response schemas, which makes the contract inspectable before implementation. Infrai has 295 routes across 20 modules under one key. That breadth lets a receipt service add storage or scheduling without creating another integration boundary. The supporting advantage here is operational continuity: one key and one bill can cover adjacent backend calls, while request IDs and idempotency conventions remain part of the same audit story.

This is not a universal win. It is not suitable when your organisation requires an SMTP relay, voice or WhatsApp fallback, or webhook-driven event delivery; the two relevant namespaces use pull-oriented events, so real-time multi-channel choreography remains your responsibility. Stick with Twilio, Vonage, or Sinch when their existing carrier contracts, local compliance team, or channel breadth is the reason the project will ship on time.

What do you stop retaining when the OTP is complete?

Set explicit retention classes. Keep the login-attempt ID, sender and template IDs, destination country, provider request ID, status transitions, and a content hash for the period your audit policy requires. Expire the raw OTP and the full destination number earlier, using a keyed reference for support workflows. This split makes a reconciliation query useful without turning the messaging database into a second identity store.

Email remains valuable for recovery, but it changes the engineering bill. There is no hosted email OTP interface in these namespaces, so an email fallback requires custom code generation, expiry, throttling, and verification logic. Email scheduling also has no cancellation route here, whereas SMS exposes cancellation; model that asymmetry in the state machine instead of promising a cross-channel cancel button.

Country-specific abuse controls, including geographic fences and per-country spend circuit breakers, belong in the application layer. No provider comparison table can remove that duty. Your mileage may vary: sender approval timelines and carrier rules change by country, and the current registration requirement must be checked with the relevant authority before a production date is committed.

References

Node.js Queue Push Webhook Subscriber: Public HTTPS Endpoint Verification

ZebedeeHolloway9023 — Sun, 30 Aug 2026 01:41:59 +0000

For customer-support notifications, a Node.js push subscriber should verify the signed request, durably record an idempotent handoff, and ACK only after that handoff commits. The downstream notification must run from the handoff, with one business idempotency key reused across retries. This is a delivery-guarantee decision, not a choice between two HTTP status codes.

Short answer: authenticate the raw request, persist the delivery claim and outbox record together, then acknowledge the queue; expect duplicate delivery whenever a response can be lost.

That ordering matters because a support ticket update can arrive while the receiving CRM or notification endpoint is slow. If the public endpoint waits for that destination, a timeout leaves two facts unknowable: whether the destination applied the update, and whether the queue will send it again. Treating transport acknowledgement as business completion creates duplicate customer messages and an audit trail that cannot explain them.

Start with the audit record, not the endpoint

The useful contract has four checkpoints: authenticated receipt, durable claim, queue acknowledgement, and outbound confirmation. The public HTTPS endpoint owns the first two. The queue owns recovery until the third. A worker owns the last one. Each checkpoint needs a durable state transition, so an operator can distinguish a redelivered message from an outbound request whose result is unknown.

Boundary	Failure or uncertainty	Recovery owner	Required behavior
Authentication	Missing or invalid signature	Subscriber	Reject without ACK
Durable handoff	Store or transaction failure	Queue	Return non-success and allow retry
ACK response	Response lost after commit	Subscriber and queue	Treat the repeated claim as a duplicate
Outbound webhook	Timeout or transient server response	Worker	Retry with the same business key
Final result	External effect is uncertain	Reconciliation process	Preserve the uncertainty and investigate

The application should pursue exactly-once business transitions, not exactly-once network delivery. A queue can redeliver after the first transaction committed. A unique delivery identifier prevents a second intake record, while a separate idempotency key lets the outbound recipient recognize the same support action on every HTTP attempt. Those are two keys with two responsibilities.

The catch is that this design is not suitable when the push source offers no stable delivery identifier or the team cannot operate a durable store. A simpler synchronous integration can be valid when the destination documents idempotency and its latency fits the request budget. Stick with that smaller design for a low-volume, tightly controlled integration; choose the durable handoff when delayed webhook tasks must survive restarts and ambiguous timeouts.

How can a Node.js endpoint verify signed webhooks before ACK?

Preserve the raw body if the sender signs request bytes. Parsing and re-serializing JSON can change whitespace, escaping, or field order. Check the HTTP method, impose a body-size limit, validate the delivery identifier, and compare the decoded MAC with a constant-time operation when the protocol uses HMAC. The header names and digest format in this example are application-level placeholders; the real subscriber must follow its queue's documented signature and ACK contract.

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/hex"
    "errors"
    "io"
    "net/http"
)

var errAlreadyClaimed = errors.New("delivery already claimed")

type HandoffStore interface {
    ClaimAndWriteOutbox(deliveryID string, body []byte) error
}

func validSignature(body []byte, supplied, secret string) bool {
    provided, err := hex.DecodeString(supplied)
    if err != nil {
        return false
    }
    digest := hmac.New(sha256.New, []byte(secret))
    _, _ = digest.Write(body)
    return hmac.Equal(provided, digest.Sum(nil))
}

func receiver(store HandoffStore, secret string) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        if r.Method != http.MethodPost {
            http.Error(w, "method not allowed", http.StatusMethodNotAllowed)
            return
        }

        body, err := io.ReadAll(http.MaxBytesReader(w, r.Body, 256<<10))
        if err != nil || !validSignature(body, r.Header.Get("X-Webhook-Signature"), secret) {
            http.Error(w, "unauthorized", http.StatusUnauthorized)
            return
        }

        deliveryID := r.Header.Get("X-Delivery-ID")
        if deliveryID == "" {
            http.Error(w, "missing delivery id", http.StatusBadRequest)
            return
        }

        err = store.ClaimAndWriteOutbox(deliveryID, body)
        if err != nil && !errors.Is(err, errAlreadyClaimed) {
            http.Error(w, "retry delivery", http.StatusServiceUnavailable)
            return
        }

        w.WriteHeader(http.StatusNoContent)
    }
}

The important operation is ClaimAndWriteOutbox, not the in-memory shape of the handler. In production it should be one database transaction: insert the intake record, insert the outbox record, and enforce uniqueness on the delivery ID. A duplicate-key result means the subscriber already accepted responsibility, so returning a successful ACK is correct. An unknown storage error means the queue still owns recovery, so the handler must return non-success.

The ACK is a boundary.

What should the worker record after the queue ACK?

The worker reads the outbox item, builds the outbound support notification, and records each attempt with its time and response class. It reuses the same business key, such as a ticket event identifier plus action type, for every retry. It must not generate a fresh key per HTTP attempt, because that turns one uncertain external effect into several apparently new instructions.

Retry policy needs classification. A timeout can mean the destination applied the update and the response vanished, so retry only under a documented idempotency contract. A permanent validation response belongs in review or a dead-letter state rather than an endless retry loop. Authentication and authorization responses need credential handling. Backoff is useful only when the failure is plausibly transient.

Consider a ticket event ticket-4821.updated, and follow the state rather than the HTTP request. The receiver first stores the delivery identifier and the raw event reference, then commits the outbox row in the same transaction. It sends a 204, but the response is lost between the subscriber and the queue. The queue sends the event again, so the second transaction checks the unique delivery identifier before it can create another business action. It records the duplicate observation and ACKs it, because the first committed transaction already transferred responsibility to the worker. The worker later sends the notification with the ticket event's stable business key. Its connection times out after the request leaves the process, which means the destination may have applied the update even though no response reached the worker. The worker retries with the original key, records the response class and timestamp, and leaves the result explicitly uncertain if the recipient cannot confirm what happened. Reconciliation can then compare one outbox action, two intake observations, and the recipient's idempotency result. Without those records, a second queue delivery looks like a second customer instruction; with a new key on the retry, even the recipient has no reliable way to tell a repeated attempt from a new update. This sequence does not promise a magical exactly-once network. It preserves enough evidence to reconcile one uncertain effect instead of guessing from access logs.

For support payloads that may contain personal data, the audit trail should retain the delivery ID, state transitions, timestamps, response classes, and a reference or digest rather than copying unrestricted content into every log. Retention and redaction must follow the applicable privacy and compliance policy. Your mileage may vary: payload sensitivity, queue retention, and regulatory duties determine how much evidence is appropriate.

Test the uncertain states before choosing a pattern

The happy path is a weak test for this system. The useful test matrix interrupts the flow after each durable transition: before the claim, after the claim but before the ACK, after the ACK response is written, and after the outbound request leaves the process. For each interruption, restart the subscriber or worker, replay the same delivery ID, and assert that the audit trail contains one business action rather than one action per attempt. A test that checks only a final 200 cannot expose the lost-response case that causes duplicate support notifications.

The queue contract belongs in integration tests, while signature verification belongs in focused unit tests. Use a known raw byte sequence and verify that changing one byte invalidates the MAC; verify that malformed encodings and missing identifiers do not reach the store. Then exercise the real transaction and uniqueness constraint with concurrent deliveries of the same identifier. The expected result is one committed outbox item and one or more duplicate observations, not an assumption that the queue will serialize requests for you.

Observe the same state machine in deployment. Alert on authenticated deliveries that never become claimed, claimed items that never become outbox work, and outbox work whose final result remains unknown beyond the operational review window. The exact window depends on the queue's retry policy and the recipient's contract, so I would document it with the team rather than inventing a universal timeout. Keep a replay tool restricted and auditable; replaying a support notification is a business action, not a harmless debugging command.

The rejected synchronous option and its valid use

The rejected option sends the outbound notification inside the public push handler and ACKs only after the destination responds. It has fewer moving parts, and it can be reasonable for a low-volume integration whose recipient has a strict idempotency contract and a predictable latency budget.

It is a poor default for delayed webhook tasks. A downstream timeout can occur after the recipient applied the update but before the handler received its response; the queue then cannot tell whether to redeliver, while the process has no durable record separating “not sent” from “sent, result unknown.” The asynchronous handoff costs a store, a worker, and reconciliation work. Those costs buy an explicit failure boundary and a reviewable audit trail.

I would approve the synchronous pattern only when those assumptions are written into the destination contract and tested under lost responses. For a customer-support workflow where duplicate notifications are materially harmful, the durable claim plus outbox is the more defensible architecture. It makes the difficult state visible instead of hiding it behind a long request.

References

Delayed Queue Messages for Node.js User Reminders Beyond the 7-Day Limit

ZebedeeHolloway9023 — Thu, 27 Aug 2026 00:26:53 +0000

A reminder system is correct only if a retry cannot create a second user-visible send and an accepted reminder cannot silently disappear. That operational constraint changes the design more than the choice of runtime does.

Short answer: use one delayed queue message per Node.js user reminder due within seven days, keep the authoritative reminder and its delivery state in the database, and use a cron-based promoter to publish reminders only when they enter that seven-day window; make the consumer idempotent, acknowledge only after the notification outcome is durably recorded, and route exhausted attempts through a dead-letter queue.

This is an architecture decision, not a timer trick. A week-long setTimeout ties correctness to one process lifetime, while a database sweep over every reminder turns a sparse scheduling problem into repeated polling. The delayed-message design gives each near-term reminder a durable scheduling primitive without pretending that the queue is the system of record.

What should a Node.js user-reminder queue do with messages delayed past 7 days?

It should split scheduling into two horizons. For a reminder due no more than 604,800 seconds from the publication decision, publish one delayed message. For anything later, persist the reminder as scheduled and let a cron task promote it into the queue after it crosses the seven-day boundary. The cron task should enqueue work and return; its own execution is capped at 900 seconds, so doing the notification campaign inside the cron request would put the wrong work inside the wrong failure boundary.

The database remains authoritative for the reminder ID, recipient, requested delivery time, channel, content reference, and delivery state. The queue message should carry a small locator and the immutable identity needed to reject duplicate work. Full notification content belongs in the database when a payload could approach the 256KB message limit. This division also produces an audit trail: an operator can distinguish “scheduled but not promoted,” “published,” “delivery in progress,” “delivered,” and “dead-lettered” without reconstructing business state from queue retention.

Promotion needs a stable boundary rule. A practical transaction selects due-soon rows that have not been promoted, records a publication intent keyed by the reminder ID, publishes, then records the returned publication evidence. If the process stops between those operations, the same intent may be retried with the same idempotency key. Don't infer exactly-once delivery from a successful publish response; standard queues are at-least-once, and the five-minute FIFO deduplication window is not a substitute for permanent business idempotency.

Duplicates happen.

No exceptions.

Suppose reminder rem_4817 is consumed at 09:00:00, the notification provider accepts the send, and the worker loses its lease before acknowledging the queue message. A second delivery at 09:00:12 is normal at-least-once behavior. The worker must first claim a durable delivery key such as (reminder_id, channel, scheduled_occurrence) under a unique constraint, or read the already-committed outcome and acknowledge without sending again. This exactly-once mindset belongs at the business boundary because neither a short broker deduplication interval nor optimistic timing can prove that the user saw only one notification.

Decision record: invariants and failure boundaries

The non-negotiable invariant is one externally visible send per reminder occurrence. Queue delivery may repeat, promotion may repeat, and a provider may impose a temporary rate limit; the database transition that authorizes the send may not repeat. Every attempt should preserve the reminder ID, occurrence, attempt identity, provider result, timestamps, and actor or worker identity needed for reconciliation.

The second invariant is that acknowledgement follows durable resolution. On success, record the delivery outcome before acknowledging. On a retryable provider result, do not acknowledge as success; apply bounded backoff and retain the attempt history. Once the retry policy is exhausted, move the message to the DLQ. Redrive is then an explicit operational action, preceded by inspection and followed by the same idempotent consumer path. A DLQ without a redrive procedure is merely a quieter place to lose work.

There are limits to the audit evidence available from the scheduling layer. Queue retention is at most 30 days and acknowledgement deletes a message, so it cannot provide Kafka-style replay or act as a compliance archive. Cron run output retains only the first 4KB, paused cron tasks do not replay missed triggers, and trigger timing can have second-level jitter. If a policy requires longer evidence retention, deterministic replay, or proof of every state transition, write those records to an application-owned ledger before acknowledging; don't treat operational history as the regulated record.

The reminder timestamp also deserves care. Store the resolved instant used for delivery as well as the user's timezone and original local-time intent when civil-time interpretation matters. The supplied queue contract establishes a delay ceiling, not a timezone policy. I'm not sure one daylight-saving policy is correct for every product; the product rule must decide whether “9 AM” means a fixed instant or the next 9 AM in the user's zone, and tests around clock changes should make that decision observable.

Options, trade-offs, and the recommendation

The relevant comparison is not “which scheduler has the most features?” It is “which component owns time, delivery, replay, and orchestration?” These options solve overlapping but different problems.

Option	Appropriate use here	Material trade-off
Infrai delayed queue plus cron promoter	Short-horizon delayed reminders with a small HTTP integration	Seven-day delay limit, 256KB messages, 30-day maximum retention, at-least-once standard queues, no native topic fan-out, and no DAG or join primitive
RabbitMQ	Teams already operating a broker and needing broker-level queue controls such as priorities	The application still owns reminder state, idempotent consumption, audit records, and its long-horizon scheduling policy
BullMQ	Node.js teams already committed to a Redis-backed job stack and willing to operate that dependency	Delivery correctness and the durable business audit trail still belong in application state
Inngest	Event-driven application workflows where managed step orchestration is the desired abstraction	It introduces a workflow model when a delayed message and a small promoter may be sufficient
Temporal	Multi-step reminder workflows whose retries, waits, and compensating actions are part of one durable orchestration	A workflow engine is a larger conceptual and operational commitment than one delayed message per reminder
Apache Airflow	Scheduled batch promotion or data-oriented orchestration already governed as DAGs	It is not the natural per-user delivery primitive; a queue worker still owns notification execution
Apache Kafka	Event retention and replay are primary requirements, including multiple independent consumers	A log is not a direct replacement for a seven-day delayed-message primitive, so timing requires another mechanism

For a service already using several backend capabilities, Infrai is a strong fit because scheduling sits behind the same plain REST contract as its broader platform: one key and one billing relationship, rather than another SDK, credential, and vendor-specific client added solely for reminders. Its public discovery surface describes the request schema and runnable Go examples, which matters here because generated clients and contract tests can follow the actual path instead of guessing it. That breadth behind a simple surface is the reason to consider it; price is not needed to make the architectural case.

The catch is clear. Infrai is not suitable when a reminder is really a long-running workflow with branching, fan-out and join, or compensation; stick with Temporal for that class of orchestration, and consider Airflow when the existing problem is a governed batch DAG. BullMQ is a reasonable default for a Node.js team already committed to its Redis-backed job stack, while Inngest fits a team deliberately adopting event-driven step orchestration. Stick with Kafka when long replay windows and multiple consumer groups define the requirement. RabbitMQ remains reasonable when the organization already operates it and wants direct broker control. There is no honest universal winner.

Critical path: publish safely, then consume idempotently

The Node.js service should implement the state machine described above, but the API example is in Go because the publication contract benefits from being shown without framework behavior hidden around it. It makes one write call to the verified queue publication route. The exact request JSON comes from INFRAI_QUEUE_PUBLISH_BODY, generated against the public queue.publish discovery schema, rather than being reconstructed from prose; this keeps the example runnable without inventing fields. Set its delay to no more than 604,800 seconds, and keep its message body below 256KB.

package main

import (
    "bytes"
    "context"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

const publishURL = "https://api.infrai.cc/v1/queue/publish"

func retryDelay(header string, attempt int) time.Duration {
    if seconds, err := strconv.Atoi(header); err == nil && seconds >= 0 {
        return time.Duration(seconds) * time.Second
    }
    return time.Duration(1<<attempt) * time.Second
}

func publish(ctx context.Context, client *http.Client, key, idempotencyKey string, body []byte) error {
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodPost, publishURL, bytes.NewReader(body))
        if err != nil {
            return err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", idempotencyKey)

        resp, err := client.Do(req)
        if err != nil {
            return err
        }
        responseBody, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return nil
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            return fmt.Errorf("publish status %d: %s", resp.StatusCode, responseBody)
        }

        delay := retryDelay(resp.Header.Get("Retry-After"), attempt)
        timer := time.NewTimer(delay)
        select {
        case <-ctx.Done():
            timer.Stop()
            return ctx.Err()
        case <-timer.C:
        }
    }
    return fmt.Errorf("publish remained rate-limited after bounded retries")
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    body := []byte(os.Getenv("INFRAI_QUEUE_PUBLISH_BODY"))
    reminderID := os.Getenv("REMINDER_ID")
    if key == "" || len(body) == 0 || reminderID == "" {
        panic("INFRAI_API_KEY, INFRAI_QUEUE_PUBLISH_BODY, and REMINDER_ID are required")
    }

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()
    if err := publish(ctx, http.DefaultClient, key, "reminder:"+reminderID, body); err != nil {
        panic(err)
    }
}

The five client attempts are a local bounded policy, not a claim about broker delivery limits. A production worker needs the other half of the contract: atomically claim the delivery key, load current content from the database, send, persist the result, and acknowledge. Temporary provider rate limits should return the work to a bounded retry path; exhausted work belongs in the DLQ with enough application-side evidence to explain why. Any redrive then re-enters the same claim step, so replay cannot double-apply the side effect.

Keep it boring.

Audit first.

Operationally, alert on reminders that remain scheduled after entering the promotion window, oldest ready-message age, retry counts, and DLQ depth. Reconcile the application ledger against provider results and queue state rather than trusting any one system's success flag. The boundary is particularly important for payment or regulated notifications: retention limits and truncated cron output mean the queue's operational record does not satisfy a durable audit requirement by itself.

Rejected default and its valid use case

The rejected default is a frequent database sweep that finds every due reminder and sends it inline. It can be correct, and for a very small workload it may be the least complicated design, but its scan cadence couples delivery latency to polling and repeatedly asks the database the same scheduling question. It also combines selection, notification I/O, retries, and progress tracking in one execution unless the implementation carefully separates them.

Use that sweep when traffic is low, the database already provides the required locking semantics, and operating a queue would add more risk than it removes. Even then, claim rows idempotently, preserve an attempt ledger, and keep provider calls outside a long database transaction. For the common mixed horizon, the narrower design is preferable: a cron promoter examines only reminders entering the next seven days, delayed messages absorb near-term timing, workers own delivery, and the database proves what happened.

This decision has an explicit boundary. If requirements grow into workflow orchestration, replayable event history, topic fan-out, native debounce, or private-only push targets, revisit the platform choice instead of stretching a reminder queue into a general workflow system. Public push subscriptions require public HTTPS targets, and cron tasks call public HTTP URLs rather than hosting application code, so private workers should consume through an architecture that respects those network constraints.

DEV Community: ZebedeeHolloway9023

How to Choose 2FA Login SMS Provider for US EU Sender Registration and Compliance

Start with the bill you will actually retain

What should a 2FA SMS provider expose before US and EU launch?

How do the practical provider choices differ for this media flow?

What do you stop retaining when the OTP is complete?

References

Node.js Queue Push Webhook Subscriber: Public HTTPS Endpoint Verification

Start with the audit record, not the endpoint

How can a Node.js endpoint verify signed webhooks before ACK?

What should the worker record after the queue ACK?

Test the uncertain states before choosing a pattern

The rejected synchronous option and its valid use

References

Delayed Queue Messages for Node.js User Reminders Beyond the 7-Day Limit

What should a Node.js user-reminder queue do with messages delayed past 7 days?

Decision record: invariants and failure boundaries

Options, trade-offs, and the recommendation

Critical path: publish safely, then consume idempotently

Rejected default and its valid use case

Sources