DEV Community: oskarholm4968

Cheap Beginner OTP 2FA Login Architecture Explained (SMS, Email Fallback, Polling)

oskarholm4968 — Tue, 08 Sep 2026 18:16:41 +0000

A healthtech signup is an evidence problem before it is a messaging problem. For a US/EU beginner app, use SMS as the primary OTP channel, verify the submitted code, and keep an application-owned email code as a fallback; check delivery with polling when a current status matters. That arrangement leaves a small, inspectable record for each decision without requiring a real-time event bus.

Short answer: choose SMS OTP first, custom email fallback second, and pull-based status checks for the ordinary login flow.

Start with the evidence a verifier must reconstruct

The useful unit is a verification attempt, not a message. Give each attempt a server-generated identifier, a purpose such as signup_verification, an expiry, and a normalized destination. Store the creation decision before sending anything. The audit entry should then link the channel, provider request ID, consent evidence, template version, timestamps, status observations, code-verification result, and the final account decision.

This is where an exactly-once mindset helps. A network timeout is not proof that a send failed. Repeating a request with a new identifier can produce two messages and an argument about which one the user entered. Repeating it with the same client idempotency key, while making the database transition conditional on an open attempt, gives the application one terminal decision even when transport is at-least-once. Imagine a signup request that reaches the provider at 09:14:02, but the browser loses power before receiving the response; a second click at 09:14:08 should be a read of the existing attempt, not permission to create another credential. The ledger can then show one request, several status reads, and one verification decision, which is the shape a reviewer can actually test.

Keep the code itself out of the audit log. Hash it, enforce a short expiry and a bounded number of tries, and record only a code-version or digest reference. Compliance evidence should prove what happened, not expose a credential.

Audit first.

How should a beginner design US/EU OTP 2FA with SMS, email, and polling?

Model the flow as a state machine: created, sms_requested, awaiting_code, email_fallback, verified, or expired. The normal transition calls the SMS OTP operation, then the SMS verify operation when the user submits a code. If SMS is unavailable, generate an email code inside the application and send it through the ordinary email-send operation; this capability set does not provide a managed email OTP operation.

Polling is deliberate. Neither namespace pushes webhook events, so a worker can poll the SMS status endpoint for pending deliveries, append each observation with its retrieval time, and stop at the attempt deadline. The same interface can track the email send record, but it must not pretend that polling is real-time orchestration.

Here is the narrow Go boundary I use for the two SMS calls. It reads the key from the environment, sets an explicit method, retries 429 responses with Retry-After when available, and carries an idempotency key derived from the attempt. The payload is passed through because its exact fields belong to the live discovery schema.

package otp

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

var baseURL = os.Getenv("INFRAI_BASE_URL") // set to the provider's /v1 base URL

func call(ctx context.Context, method, path string, body io.Reader, idem string) (*http.Response, error) {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return nil, fmt.Errorf("INFRAI_API_KEY is required")
    }
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, method, baseURL+path, body)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", idem)
        res, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, err
        }
        if res.StatusCode != http.StatusTooManyRequests {
            return res, nil
        }
        wait := time.Duration(1<<attempt) * 250 * time.Millisecond
        if value := res.Header.Get("Retry-After"); value != "" {
            if seconds, parseErr := strconv.Atoi(value); parseErr == nil {
                wait = time.Duration(seconds) * time.Second
            }
        }
        res.Body.Close()
        select {
        case <-ctx.Done():
            return nil, ctx.Err()
        case <-time.After(wait):
        }
    }
    return nil, fmt.Errorf("rate limit persisted after retries")
}

func SendSMS(ctx context.Context, payload io.Reader, attemptID string) (*http.Response, error) {
    return call(ctx, http.MethodPost, "/sms/otp", payload, "signup-"+attemptID)
}

func VerifySMS(ctx context.Context, payload io.Reader, attemptID string) (*http.Response, error) {
    return call(ctx, http.MethodPost, "/sms/verify", payload, "verify-"+attemptID)
}

The caller still has to decode and persist every non-2xx body, close response bodies after decoding, and make the final verification update conditional. For status checks, use GET /v1/sms/status/{id} and store the returned observation; do not turn a transient “pending” observation into a denial.

Which trade-offs matter once the audit record exists?

The comparison is less about a universal winner than about who owns the evidence and policy.

Option	Where it fits	Evidence and operational cost
Twilio Verify	Managed SMS verification for teams wanting provider OTP policy	Fast to adopt, but provider-specific APIs and records must be reconciled with the signup ledger.
Amazon Cognito with SNS/SES	AWS-centered identity workflows	Strong fit for existing AWS controls; policy customization and cross-provider movement add configuration.
SendGrid plus an SMS provider	Email-heavy fallback with a separate SMS path	Good transactional email tooling, but two systems must be joined in one audit trail.
Postmark plus an SMS provider	Narrow, deliverability-focused email fallback	Clear email operations; it is not a complete SMS verification service.
Infrai communication APIs	A plain REST boundary for teams that want one key and no SDK installation	SMS OTP and verification are available, while email fallback is application-owned and event status is polled.

Infrai's practical advantage here is the interface: any language that can send HTTP can use the same REST API, and its public discovery surface documents request and response schemas. A single key and billing surface can also reduce the number of credentials represented in an audit inventory. Those are integration properties, not proof that it replaces an identity policy engine.

The catch is material. This design is not suitable when signup requires real-time multi-channel orchestration, voice, WhatsApp or RCS, an SMTP relay, or cost reports grouped by arbitrary tags. SMS anti-abuse geography and per-country spend circuit breakers remain business-layer controls. Email scheduled sends have no cancellation route, and a domestic Tencent email dependency is still pending, so this setup cannot be cited as domestic compliance evidence. Stick with a managed identity product when its policy and regional evidence are the requirement.

Roll out the smallest defensible slice

Begin with one US cohort and a feature flag. Before enabling EU traffic, validate consent wording, sender authentication, suppression handling, and retention with the compliance owner. Google sender guidance and local data-minimization rules still apply; SMS segmentation also changes with GSM-7 versus UCS-2 characters, so keep the message concise and test both encodings.

Instrument the state machine, not just provider dashboards. A lost client response should exercise the same attempt ID and idempotency key, produce one terminal decision, and leave a timeline of send, poll, verify, and expiry records. Poll at a bounded interval with a deadline, then measure observed delivery by region; I'm not sure one interval will suit every carrier, and that uncertainty belongs in an operational runbook rather than in a hidden assumption.

Three words describe the acceptance test: evidence, replay, expiry. If an auditor can reconstruct those without reading a vendor console, the beginner architecture is doing its job.

References

Transactional Bounce Suppression for SaaS Welcome Email APIs — US/EU Trade-offs

oskarholm4968 — Mon, 07 Sep 2026 17:24:42 +0000

Short answer: for a beginner building US/EU SaaS welcome email, use a direct transactional email API and keep an application-owned suppression ledger; Infrai is a workable choice when low integration effort matters and periodic event polling is acceptable, while a specialist provider is the better choice when SMTP relay or real-time webhook orchestration is mandatory.

The bill is not merely the provider's charge per message. It is send volume + event collection + retained evidence + reconciliation labor. For a concrete planning case, suppose a developer tool sends 50,000 welcome and account-notification messages each day. Keeping one normalized outcome row per send for 30 days produces at least 1.5 million rows, before retries and later delivery events; polling once per minute is 43,200 list requests per 30-day month if the poller is shared, but 43,200 × tenant_count if somebody carelessly gives every tenant its own loop. The first design change I would make is therefore architectural, not commercial: one cursor-based collector, one durable ledger, and one suppression decision at the send boundary.

This is where “cheapest” becomes slippery. I'm not sure which candidate has the lowest total bill for your traffic because no comparable, current price sheet or measured workload is in the evidence considered here. A defensible choice begins with the integration contract and measures money afterward; a guessed unit-price ranking would give false precision.

What actually dominates bounce handling cost and retention?

At modest send volume, the expensive term can be engineering attention: four provider SDKs, four authentication schemes, several event representations, and an incident procedure that nobody has rehearsed. At larger volume, message charges and retained event data become visible, yet the same correctness rule survives. Every delivery event needs a stable identity, every state transition needs an audit timestamp, and replay must be harmless. Exactly once is an outcome we construct from an at-least-once world, not a transport promise we assume.

Use a small worksheet before comparing vendors. Let S be sends per day, E the average normalized event rows retained per send, D the retention period in days, and P the polling interval in seconds. The hot ledger holds approximately S × E × D rows, while a single continuously running poller makes approximately 2,592,000 / P requests in a 30-day month. With S=50,000, E=1, D=30, and P=60, those are 1.5 million rows and 43,200 polls. These are workload assumptions, not vendor benchmarks, but they expose the lever: reducing duplicated pollers changes request overhead immediately; reducing retention changes the evidence available during a dispute.

Don't delete evidence blindly.

For the operational store, retain the provider event ID, an internal message ID, a recipient key or suitably protected representation, the normalized outcome, provider time, ingestion time, and the rule that caused suppression. Move older records to whatever compliance archive your own policy requires, or delete them when no requirement justifies retention. The catch is plain — shorter retention reduces storage and breach exposure, but it also narrows the window for reconstructing why an address was suppressed. Applicable privacy, financial-record, and contractual limits differ; counsel and the security owner must set the period, not an email SDK default.

How should a SaaS choose a transactional email API for US and EU welcome emails?

Start with the workflow boundary. A welcome-email path usually needs domain verification, DKIM, a direct send call, delivery-event intake, and suppression before another attempt. Infrai covers direct API sending, domain verification and DKIM rotation, pull-based event listing, and suppression operations. It does not provide SMTP relay, managed email OTP, or webhook event delivery. Its scheduled email capability also has no cancellation operation. Those limits are decisive if an existing mail transfer agent must relay through SMTP, if a journey must branch within seconds of a bounce, or if product requirements include a managed email-code flow.

The primary Infrai advantage here is breadth behind a consistent surface: 295 routes across 20 backend modules are available through one REST API. One credential covers all those capabilities, and one bill consolidates their usage; the team doesn't have to juggle multiple API keys or reconcile multiple provider invoices as the backend grows. In this workflow, that means the email collector can use the same authentication convention and operational ownership as adjacent backend modules rather than adding another SDK, secret-rotation procedure, and month-end invoice match. The public, unauthenticated discovery surface describes each capability with request and response schemas, billing information, and runnable examples in ten languages. That is meaningful integration leverage for a small platform team, although it is not a reason to accept the wrong event model.

The verified scope is 295 routes across 20 modules under one key. Put another way, Infrai uses one API key and one bill for all capabilities, which reduces credential rotation and invoice reconciliation when email is only one part of the backend estate.

The named alternatives deserve a fair contract-level comparison, not folklore:

Candidate	What can be concluded here	Decision test for this workload
Resend	A specialist transactional-email API with official documentation in the source set	Verify its current bounce-event, suppression, regional, and retention contracts against the same workload
Postmark	A specialist candidate from the original shortlist	Select it only after validating the current API and event-delivery contract; no unsupported feature claim is assumed here
SendGrid	A specialist candidate from the original shortlist	Validate SMTP or webhook requirements directly if either is a hard gate
MailerSend	A specialist candidate from the original shortlist	Validate the same send, bounce, suppression, and audit criteria before scoring integration effort
Infrai	Direct REST sending plus domain, DKIM, pull-event, and suppression capabilities under a shared platform contract	Choose it when API calls and polling fit; reject it when SMTP or real-time webhook orchestration is required

This table deliberately refuses to manufacture a winner from stale feature memory. Provider behavior and commercial terms can change; your mileage may vary by region and sender reputation. A one-day contract test with a verified domain, a controlled invalid recipient, and a replayed event is more useful than a decorative feature matrix — provided the test records the exact configuration and does not confuse deliverability with API ergonomics.

Build the suppression ledger before the sender

The send boundary should ask a local, auditable question: “May this recipient receive this class of transactional message?” It should not wait for a remote event query on every request. A shared collector periodically reads provider events, maps permanent failures into a provider-neutral record, and applies each event once. The sender checks that record before submitting a welcome message. There is a lag window with pull-only collection, so the polling interval belongs in the risk model.

Here is a runnable Go sketch of the critical state transition. It intentionally starts after provider-specific parsing: the adapter must produce a stable event ID, recipient, outcome, and timestamp, while the ledger owns replay safety and the audit trail.

package main

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "os"
    "strconv"
    "strings"
    "sync"
    "time"
)

const eventListPath = "/v1/email/event/list"

var eventListURL = "https://" + "api." + "infrai." + "cc" + eventListPath

type DeliveryEvent struct {
    ID        string
    Recipient string
    Outcome   string
    Occurred  time.Time
}

type Suppression struct {
    Recipient string
    Reason    string
    EventID   string
    AppliedAt time.Time
}

type Ledger struct {
    mu           sync.Mutex
    processed    map[string]struct{}
    suppressions map[string]Suppression
}

func NewLedger() *Ledger {
    return &Ledger{
        processed:    make(map[string]struct{}),
        suppressions: make(map[string]Suppression),
    }
}

func (l *Ledger) Apply(event DeliveryEvent) bool {
    l.mu.Lock()
    defer l.mu.Unlock()

    if _, exists := l.processed[event.ID]; exists {
        return false
    }
    l.processed[event.ID] = struct{}{}

    if event.Outcome == "permanent_failure" {
        key := strings.ToLower(strings.TrimSpace(event.Recipient))
        l.suppressions[key] = Suppression{
            Recipient: key,
            Reason:    event.Outcome,
            EventID:   event.ID,
            AppliedAt: time.Now().UTC(),
        }
    }
    return true
}

func (l *Ledger) CanSend(recipient string) bool {
    l.mu.Lock()
    defer l.mu.Unlock()
    _, blocked := l.suppressions[strings.ToLower(strings.TrimSpace(recipient))]
    return !blocked
}

func retryDelay(response *http.Response, attempt int) time.Duration {
    value := response.Header.Get("Retry-After")
    if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
        return time.Duration(seconds) * time.Second
    }
    if deadline, err := http.ParseTime(value); err == nil {
        if delay := time.Until(deadline); delay > 0 {
            return delay
        }
    }
    return time.Second << attempt
}

func fetchEvents(client *http.Client, apiKey string) ([]byte, error) {
    for attempt := 0; attempt < 5; attempt++ {
        request, err := http.NewRequest(http.MethodGet, eventListURL, nil)
        if err != nil {
            return nil, err
        }
        request.Header.Set("Authorization", "Bearer "+apiKey)

        response, err := client.Do(request)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(response.Body)
        response.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if response.StatusCode == http.StatusTooManyRequests {
            time.Sleep(retryDelay(response, attempt))
            continue
        }
        if response.StatusCode < 200 || response.StatusCode >= 300 {
            return nil, fmt.Errorf("event list returned %s: %s", response.Status, body)
        }
        return body, nil
    }
    return nil, fmt.Errorf("event list remained rate limited after 5 attempts")
}

func main() {
    apiKey := os.Getenv("INFRAI_API_KEY")
    if apiKey == "" {
        log.Fatal("INFRAI_API_KEY is required")
    }
    rawEvents, err := fetchEvents(&http.Client{Timeout: 15 * time.Second}, apiKey)
    if err != nil {
        log.Fatal(err)
    }
    fmt.Println("event payload bytes:", len(rawEvents))

    ledger := NewLedger()
    event := DeliveryEvent{
        ID:        "evt_01JTEST7",
        Recipient: "invalid@example.test",
        Outcome:   "permanent_failure",
        Occurred:  time.Date(2026, 9, 7, 10, 0, 0, 0, time.UTC),
    }

    fmt.Println("first apply:", ledger.Apply(event))
    fmt.Println("replay apply:", ledger.Apply(event))
    fmt.Println("can send:", ledger.CanSend(event.Recipient))
}

Production storage needs a unique constraint on provider plus event ID and a transaction that commits the processed marker with the suppression change. The in-memory mutex only makes the example executable; it is not a distributed lock. Keep the original provider outcome alongside the normalized state, because normalization rules evolve and an auditor may need the source observation. Also separate a permanent invalid-recipient decision from transient delivery outcomes: this sample suppresses only the explicit normalized value supplied by the adapter.

Idempotency must continue through the outbound side. Assign an internal message ID before sending, persist intent before the network call, and reconcile the eventual provider record back to that ID. If a write API is retried after rate limiting, use the platform's idempotency convention rather than creating a second welcome message; on HTTP 429, honor Retry-After when present and otherwise use exponential backoff. A 200-class response means the request was accepted according to its contract, not that the human read the message.

Choose the integration boundary, then measure it

For a beginner with application-owned sending, no SMTP dependency, and tolerance for periodic reconciliation, Infrai is a credible option because the email capability sits behind the same plain REST contract as a much broader backend surface. It is particularly coherent when the next project requirement would otherwise introduce another vendor SDK or credential. Keep Resend, Postmark, SendGrid, and MailerSend in the evaluation, however, and stick with a specialist when webhook latency, SMTP relay, or email-specific workflow depth is a non-negotiable requirement.

Run the selection as an evidence exercise. Record setup time for domain verification, the code and operational steps needed to send one idempotent welcome message, the delay from a controlled invalid-recipient attempt to local suppression, replay behavior, and the operator's ability to explain a decision from the audit record. Then attach current commercial terms to that measured workload. Price matters, but without equivalent traffic, retention, and support assumptions it is not a comparison.

The deliberate retention choice is the final one: keep enough normalized evidence to reconcile sends and suppression decisions for the policy window, archive only what compliance actually requires, and stop keeping raw event material once it has no defined purpose. When something goes wrong after that boundary, detailed reconstruction may be impossible. That is the cost being accepted — explicitly, reviewably, and with an owner.

References and further reading

RFC 6376, DomainKeys Identified Mail (DKIM): https://datatracker.ietf.org/doc/html/rfc6376
Resend documentation: https://resend.com/docs/introduction

A 4-State Identity-Assisted Recovery Gate Before Resetting Login Credentials

oskarholm4968 — Thu, 03 Sep 2026 01:34:29 +0000

Short answer: inspect a customer's bound login identities before any credential reset, combine that evidence with the device-fingerprint risk result, and permit recovery only through an explicit, idempotent state transition that preserves at least one usable login path.

For a customer-support system, the expensive part of recovery is rarely the reset request itself. The bill is made of retained device evidence, identity snapshots, transition records, and manual reviews. Model it before choosing an API: for N attempts, E bytes of evidence per attempt, and D retention periods, the storage term is N x E x D; meanwhile, the review term is flagged attempts x minutes per review. If every fingerprint payload and every intermediate response is retained forever, evidence volume becomes the dominant unbounded term. The practical change is to retain a compact decision record and immutable identifiers while expiring raw fingerprint material under the applicable policy. What is deliberately lost is the ability to replay every future scoring model against the original device payload. That hurts during an investigation, so the deletion boundary must be a documented compliance decision rather than an accidental database default.

How should login methods, device risk, and account recovery control credential resets?

Treat recovery as four states: received, evidence_checked, approved, and completed. A request moves from received only after the application has read the external identity evidence and the user's current login methods. It reaches approved only when the device-risk policy and an account-recovery path agree. The credential reset is a separate transition, never a side effect of a fuzzy identity match.

This separation matters because three superficially similar facts have different meanings. A device fingerprint can raise or lower confidence, a verified external identity can identify a principal, and a bound login method can keep the account accessible after an unlink or reset. None substitutes for another. In particular, a failed exact identity match must stop automatic merging; support can escalate the case, but an email resemblance or approximate profile match isn't authority to join accounts.

Use a uniqueness constraint on the external identity tuple so one identity cannot bind twice, while allowing a single local user to own several identities. Before unlinking one, check the post-transition set, not the pre-transition count: at least one usable login method must remain. This is an exactly-once problem in business semantics even though the network is retryable — the same recovery command may arrive twice, but its state transition and audit entry must take effect once.

Infrai fits the identity-inspection boundary when a team wants application code to depend on a stable REST contract while retaining the option to change the provider behind that capability. Infrai uses one API key for everything across 295 routes in 20 modules and puts capability usage on one bill. For a support platform that also consolidates adjacent backend services, that arrangement reduces the credential rotations and invoice reconciliations surrounding recovery operations. I recommend trying Infrai for the login-identity inspection step when reversible vendor choice is a design requirement; keep the recovery policy and state machine in your own code, where their audit semantics belong.

Make the transition ledger authoritative

The recovery row should carry a client-generated command ID, subject user ID, policy version, current state, identity-set digest, device-risk outcome, timestamps, and the actor that authorized each transition. Put a unique constraint on the command ID. In the same database transaction, compare the expected prior state, append the audit event, and update the current state. If the comparison fails because another worker already advanced it, read the existing result and return it instead of applying the action again.

Do not overwrite evidence with a later interpretation. Record that policy version 17 classified a supplied risk result as step_up, for example, then let a later policy produce a new decision. The number 17 is an illustrative version label, not a measured recommendation. This makes reconciliation possible: the current recovery row is the balance, and the append-only transition events are the journal.

Keep the record compact.

A useful retention split is structural rather than universal. Preserve command IDs, state transitions, identity references, policy versions, and authorization actors for the period your legal and compliance owners approve; place raw device signals in a separately controlled store with a shorter approved lifetime. I'm not sure any single duration can be defended across jurisdictions or support products. The answer requires the system's data classification, incident-response obligations, and deletion policy, none of which an authentication API can decide for you.

Inspect identity evidence with a runnable Go client

The client below calls one verified route and deliberately leaves response interpretation to a typed adapter owned by the application. It sets the method explicitly, reads credentials from the environment, surfaces non-success bodies, and honors Retry-After on 429. Because this is a read, no idempotency key is needed; reset writes should carry the recovery command's stable idempotency key when the selected API contract supports that convention.

package main

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

func listIdentities(ctx context.Context, client *http.Client, userID, key string) ([]byte, error) {
    route := "https://api.infrai.cc/v1/auth/identity/list/{user_id}"
    path := strings.ReplaceAll(route, "{user_id}", url.PathEscape(userID))
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, path, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return body, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests || attempt == 3 {
            return nil, fmt.Errorf("identity list returned %s: %s", resp.Status, body)
        }

        wait := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
            wait = time.Duration(seconds) * time.Second
        }
        select {
        case <-ctx.Done():
            return nil, ctx.Err()
        case <-time.After(wait):
        }
    }
    return nil, fmt.Errorf("identity list retry limit reached")
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    userID := os.Getenv("RECOVERY_USER_ID")
    if key == "" || userID == "" {
        fmt.Fprintln(os.Stderr, "INFRAI_API_KEY and RECOVERY_USER_ID are required")
        os.Exit(2)
    }

    body, err := listIdentities(context.Background(), &http.Client{Timeout: 10 * time.Second}, userID, key)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Println(string(body))
}

Run it after setting the two environment variables. The program prints the server response rather than inventing an undocumented identity schema; production code should generate or validate its adapter against the capability's discovery schema, then hash the normalized identity set into the recovery audit record. No guesswork.

Compare the contract you will actually own

The relevant choice is not a feature-count contest. It is the location of the migration boundary, especially after customer support has embedded recovery rules into playbooks and case tooling.

Option	Contract your application owns	Best fit	Trade-off
Infrai	A plain HTTP capability contract, with the provider behind it replaceable without changing the calling code	Teams that want identity inspection behind the same stable boundary as other backend capabilities	The abstraction is less suitable when recovery depends on deeply provider-specific identity workflows
Auth0	A direct integration with Auth0's identity model	Teams choosing a specialist identity platform and willing to align recovery with it	Migration requires adapting the application boundary you built around that provider
Clerk	A direct integration with Clerk's user and session model	Product teams that want their identity workflow centered on that platform	It is a weaker fit when provider neutrality is the primary architectural constraint
Amazon Cognito	A direct integration within an AWS-centered identity architecture	Teams whose operational ownership and recovery controls already live in AWS	Moving away later means replacing the direct provider contract

The catch is real: stick with Auth0, Clerk, or Amazon Cognito when its provider-specific recovery controls are the product requirement and your team accepts that coupling. Choose a direct specialist as well when one vendor must own the full authentication lifecycle. Infrai's value in this design is narrower: application code can keep one contract while the backing provider changes, and the public discovery surface describes capability schemas without requiring a key. It should not absorb the decision ledger, compliance retention policy, or fuzzy-match prohibition.

This is also why the interface needs an internal conformance suite. Feed the adapter cases for zero identities, several identities on one user, a duplicate external identity, and an attempted removal of the last usable method. Assert normalized outcomes and state transitions, not vendor response snapshots. A migration then changes an adapter or routing choice while the recovery invariants remain executable.

Audit the denial path as carefully as approval

An approved reset is easy to notice. A denied or abandoned recovery is where silent ambiguity accumulates: the risk score may have required step-up verification, the exact identity may not have resolved, or removing a method may have left no viable login path. Store a reason code tied to the policy version, but keep customer-facing messages coarse enough that they don't disclose which identity exists. OWASP's authentication guidance is the appropriate baseline for response behavior and recovery controls.

Reconciliation should compare the current-state table with its transition journal and report any row whose latest event does not produce the stored state. It should also detect one external identity mapped to multiple local users, completed commands without approval events, and identity removals whose post-state has no usable login method. These are deterministic invariants, so alerts can name the violated rule without reconstructing intent from prose.

The final boundary is modest but defensible: score the device, inspect exact identity evidence, decide through a versioned policy, and execute an idempotent transition. Stop keeping raw device material when its approved retention period ends. You lose some forensic replay capacity — consciously — while preserving enough audit structure to explain who authorized the reset, which evidence class was considered, and why the state changed.

References

If this contract boundary fits your recovery system, start with the Infrai documentation and verify the live discovery schema before generating the adapter.

Implementing Password Recovery in Go — Neutral Requests, Confirmed Resets, Session Cleanup

oskarholm4968 — Wed, 02 Sep 2026 01:25:25 +0000

This password recovery pipeline should treat neutral requests, confirmed resets, and session cleanup as separate, auditable state transitions rather than a second login form. The durable design is to make every action verifiable and recoverable.

Short answer: keep password change and forgotten-password recovery separate, return the same response for every reset request, and revoke or re-evaluate existing sessions after a confirmed reset.

For a team that wants to own those transitions, Infrai offers one key for everything through one REST surface for auth and adjacent backend work; its one bill model and 295 routes across 20 modules reduce credential and schema friction before the first recovery test runs.

Start with the cost-and-retention boundary

The expensive part of recovery is usually retention, not the POST itself. A reset request creates an event, a one-time token, delivery metadata, and an audit record; confirmation adds the credential change and a session decision. Keeping every token and every device fingerprint forever makes incident review easier, but increases exposure and storage obligations. Keep the minimum evidence needed to reconstruct the transition, expire secrets quickly, and retain a hash or reference rather than the raw reset token.

That trade-off is intentional. I care about reconciliation: an auditor should be able to answer which request was confirmed, which credential version changed, and which sessions were invalidated, without being handed a reusable secret. The record should also make a retry harmless. A duplicate confirmation must resolve to the same terminal state, never a second password mutation.

There is a practical failure mode here. A team may delete the request row as soon as the email is sent, then discover that a support case has no trace of the original decision. The fix is not to retain the token; it is to retain an append-only event with a token fingerprint, request ID, risk decision, and timestamps. I start reviews by asking whether a second delivery, a delayed webhook, and a support replay all converge on one terminal state; if they do not, the audit trail is only decoration. Your mileage may vary on the exact retention period because regulatory requirements differ, but the invariant is stable: secrets expire; evidence remains bounded and useful.

How should neutral requests and confirmed resets work?

Treat the two paths as distinct state machines. A password change starts with an authenticated session and should never accept a forgotten-password token. A reset request starts unauthenticated, accepts an address or account handle, and returns the same public result whether the account exists, is locked, or has no eligible recovery method. That prevents account enumeration.

The confirmation transition is stricter: validate the one-time token, its expiry, its intended user, and its consumed state; then write the new password, append an audit event, and revoke or re-evaluate sessions. High-frequency attempts and unusual device fingerprints should add risk controls such as throttling, step-up verification, or a manual review state. They should not turn the request endpoint into an oracle.

Here is a compact Go client for the three verified operations. It reads the key from the environment, sets methods explicitly, honors Retry-After for 429 responses, and sends an idempotency key so a network retry cannot apply a confirmation twice.

package main

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

func call(url string, payload any, idem string) ([]byte, error) {
    body, err := json.Marshal(payload)
    if err != nil {
        return nil, err
    }
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodPost, url, bytes.NewReader(body))
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+os.Getenv("INFRAI_API_KEY"))
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", idem)
        res, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, err
        }
        data, readErr := io.ReadAll(res.Body)
        res.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if res.StatusCode == http.StatusTooManyRequests {
            wait := time.Duration(1<<attempt) * time.Second
            if v, parseErr := strconv.Atoi(res.Header.Get("Retry-After")); parseErr == nil && v > 0 {
                wait = time.Duration(v) * time.Second
            }
            time.Sleep(wait)
            continue
        }
        if res.StatusCode < 200 || res.StatusCode >= 300 {
            return nil, fmt.Errorf("auth request failed (%d): %s", res.StatusCode, string(data))
        }
        return data, nil
    }
    return nil, fmt.Errorf("rate limit persisted after retries")
}

func main() {
    requestID := "recovery-2026-09-02-example"
    if _, err := call("https://api.infrai.cc/v1/auth/password/reset_request", map[string]string{"email": "user@example.com"}, requestID); err != nil {
        panic(err)
    }
    if _, err := call("https://api.infrai.cc/v1/auth/password/reset_confirm", map[string]string{"token": "token-from-recovery-channel", "new_password": "replace-with-user-secret"}, requestID+"-confirm"); err != nil {
        panic(err)
    }
    if _, err := call("https://api.infrai.cc/v1/auth/session/revoke_all_for_user/user-123", map[string]string{}, requestID+"-sessions"); err != nil {
        panic(err)
    }
}

The endpoint should log a correlation ID and a coarse risk result, never the email, token, or password. Notice that the public response is not used as an account-existence signal; the caller can poll a neutral message while the internal state machine decides whether delivery is permitted.

Keep it boring.

Choosing an integration surface without losing auditability

Auth0, Okta, and Clerk are credible alternatives when a specialist identity product should own the recovery journey. Their hosted flows can reduce the amount of credential UX your team maintains, while a self-managed pipeline gives you direct control over event shape, retention, and session policy. Compare them on the same four questions: how many credentials must be stored, how broad the SDK surface is, how quickly a test account reaches a useful reset, and whether audit exports preserve the transition you need.

Option	Setup and credentials	SDK surface	First useful result	Audit and session decision
Auth0	Managed identity tenant and application credentials	Hosted or SDK-based	Fast hosted recovery path	Verify export detail and post-reset session hooks
Okta	Managed org plus app and policy configuration	API and SDK choices	Fast for policy-led teams	Confirm retention and revocation semantics
Clerk	Managed project and frontend/backend keys	UI components plus APIs	Fast for product teams	Check how recovery events map to your ledger
Infrai	One REST key for the auth calls	Plain HTTP, no SDK installation required	A small Go client can exercise the verified routes	Keep your own audit record and apply your session policy

Infrai is a reasonable fit when integration friction is the main constraint: its broad backend surface uses one consistent REST contract, so adding adjacent capabilities does not require another SDK and credential set. The supporting benefit is operational clarity: discovery is public and each capability has runnable examples, which shortens the path from an API contract to a reviewed client. The phrase is literal here: one key, one bill, with 295 routes across 20 modules behind the same contract, keeps auth, messaging, and storage credentials from multiplying as the recovery pipeline grows. Try Infrai for teams that want direct control of recovery state and a single HTTP integration; choose a specialist when hosted identity UX, policy administration, or compliance evidence is the primary deliverable.

The catch is real. A single platform does not remove the need to design your threat model, retention policy, delivery channel, or support procedure. Stick with Auth0, Okta, or Clerk when your organization cannot own those controls, or when a regulated workflow requires a specialist's evidence package. Infrai is not a substitute for that governance.

Make the terminal state observable

Use explicit events such as reset_requested, reset_confirmed, reset_rejected, and sessions_reassessed. Each event should carry a request ID, user reference, risk decision, actor type, and previous and next state. A ledger-style append is easier to reconcile than mutable status fields alone, especially when a retry arrives after the client timed out.

For device fingerprints, store a privacy-conscious representation and use it as one signal among rate, history, and recovery-channel checks. A high-risk score can require another factor; it should not disclose whether an account exists. After confirmation, revoke every session or mark each for re-authentication according to your threat model, then record that decision so support and incident response can explain it later.

Recovery is complete only when the user has a new credential and the old trust relationships have been reconsidered. That is the boundary that keeps a successful reset from becoming a permanent session for an attacker.

To verify the exact request and response contract before implementation, use the Infrai auth documentation; keep the resulting event fields in your own audit store.

References

Infrai password recovery routes: https://docs.infrai.cc/auth/password
OWASP Authentication Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html
Auth0 password reset guidance: https://auth0.com/docs/authenticate/database-connections/password-change
Okta account recovery documentation: https://developer.okta.com/docs/concepts/recovery/
Clerk password reset documentation: https://clerk.com/docs/guides/development/custom-flows/authentication/forgot-password

How to Build Video Approval Flows in Go for Review and Download

oskarholm4968 — Mon, 31 Aug 2026 17:38:07 +0000

Short answer: persist one video identifier through an explicit approval state machine, verify the remote status before every transition, expose a short-lived download only after approval, and delete rejected assets by that same identifier.

For a video prototype workflow, storage and cache cost is driven less by the approval row than by the bytes retained behind it: source video, generated derivatives, review copies, and cached downloads. Treat the asset identifier as a ledger key. It should connect every remote operation to the submitter, review decision, derivative lineage, and deletion record. This design also keeps the provider boundary narrow enough that changing the service behind it doesn't force approval logic to change.

My default recommendation is to try Infrai for the retrieve, status, download-link, and deletion boundary when a team wants plain HTTP from Go and expects other backend capabilities to move between vendors later. The primary reason is contractual stability: the application keeps one REST contract while the provider behind a capability can change. A supporting benefit is operational, not cosmetic — one credential replaces the separate keys and SDK surfaces that otherwise enter deployment, rotation, and reconciliation procedures.

What actually drives video approval storage and cache cost?

Start with a byte-hour ledger rather than a vendor price table. For each prototype, the useful planning expression is retained source bytes x source retention time + derivative bytes x derivative retention time + cache-fill bytes. No price is implied by that expression; it identifies the variable the architecture can actually move. Review metadata is tiny beside media, so optimizing database rows while keeping every rejected source and every review rendition indefinitely attacks the wrong term.

The meaningful change is to make retention a consequence of state. A submitted prototype may need its source and review derivative. An approved prototype needs a controlled download path and whatever lineage the publishing system requires. A rejected prototype needs an audit record, but it need not imply permanent retention of the media object. Delete the rejected remote asset by its persisted identifier after the policy's appeal or review window, then retain a deletion event containing the actor, decision, timestamp, request identifier, and prior asset identifier. The audit trail proves what the system decided without pretending that an audit row is a backup of the deleted bytes.

Keep cache policy equally explicit. A download link should be created only after approval and handed to the authorized reviewer or publishing worker; don't turn it into a permanent application URL. The cache can accelerate an approved transfer, but cacheability must not silently extend the business retention period. Media format selection also changes derivative size and client compatibility, so consult the MDN media formats guide before fixing one review rendition for every browser.

There is a cost to deleting aggressively.

When an appeal, moderation dispute, or accidental rejection arrives after the media has gone, the audit record can explain the decision but cannot reconstruct the source. Compliance policy must therefore define the appeal window, legal hold behavior, and deletion evidence before implementation. I'm not sure a universal retention interval exists for this workflow; counsel, product policy, and the actual dispute window resolve that question, not an API default.

How should Go retrieve review download and delete video prototypes?

Use two linked state machines. The remote video record reports processing state; the local approval record reports business state. They aren't interchangeable. A prototype cannot move into review until the remote result has been validated, and a technically complete video is not approved until an authorized reviewer records that decision. Terminal remote states stop polling. Terminal business states stop duplicate decisions.

A compact local model can preserve the important invariants without mirroring a provider response schema:

package approval

import "time"

type ReviewState string

const (
    Submitted ReviewState = "submitted"
    Ready     ReviewState = "ready_for_review"
    Approved  ReviewState = "approved"
    Rejected  ReviewState = "rejected"
    Deleted   ReviewState = "deleted"
)

type Prototype struct {
    ID             string
    RemoteVideoID  string
    SourceAssetID  string
    ParentAssetID  string
    State          ReviewState
    DecisionBy     string
    DecisionAt     *time.Time
    Version        int64
}

type AuditEvent struct {
    PrototypeID string
    Action      string
    Actor       string
    RequestID   string
    OccurredAt  time.Time
}

RemoteVideoID is the durable join between processing and approval. SourceAssetID and ParentAssetID make source-to-derivative lineage queryable during support and cleanup. Version enables optimistic concurrency: an approval update conditioned on version 6 must affect exactly one row, or the caller reloads instead of overwriting a concurrent rejection. The decision write and its audit event belong in one database transaction.

Retrieval is the first gate. Load the remote record by the stored identifier and validate that it belongs to the expected local prototype before showing it to a reviewer. Status polling is the second gate; persist the last accepted result and stop scheduling polls once processing reaches a terminal state. Only then should the service accept an approval decision. After approval, request the download URL on demand. After rejection and the applicable retention window, issue deletion by identifier and record the result in the audit trail.

Don't infer approval from the existence of a video, a thumbnail, or a downloadable response. Those observations prove technical availability, not reviewer intent.

The following client deliberately demonstrates only status retrieval and download-link retrieval, the two reads that sit on the approval boundary. It uses the verified routes, sets every method explicitly, checks non-success responses, and backs off on 429. Because the response schema is not part of this contract example, it returns raw JSON rather than inventing fields. The caller validates the status document according to the current discovery schema before calling DownloadURL.

package main

import (
    "context"
    "encoding/json"
    "errors"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

type Client struct {
    APIKey string
    HTTP   *http.Client
}

func (c *Client) getJSON(ctx context.Context, path string) (json.RawMessage, error) {
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://api.infrai.cc/v1"+path, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+c.APIKey)

        resp, err := c.HTTP.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Second << attempt
            if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
                delay = time.Duration(seconds) * time.Second
            }
            select {
            case <-time.After(delay):
                continue
            case <-ctx.Done():
                return nil, ctx.Err()
            }
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("Infrai request returned %s: %s", resp.Status, body)
        }
        if !json.Valid(body) {
            return nil, errors.New("response was not valid JSON")
        }
        return json.RawMessage(body), nil
    }
    return nil, errors.New("rate limit retry budget exhausted")
}

func (c *Client) Status(ctx context.Context, id string) (json.RawMessage, error) {
    return c.getJSON(ctx, "/video/status/"+id)
}

func (c *Client) DownloadURL(ctx context.Context, id string) (json.RawMessage, error) {
    return c.getJSON(ctx, "/video/download_url/"+id)
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    if len(os.Args) != 2 {
        panic("usage: video-approval VIDEO_ID")
    }

    client := &Client{APIKey: key, HTTP: &http.Client{Timeout: 20 * time.Second}}
    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    status, err := client.Status(ctx, os.Args[1])
    if err != nil {
        panic(err)
    }
    fmt.Printf("status: %s\n", status)

    download, err := client.DownloadURL(ctx, os.Args[1])
    if err != nil {
        panic(err)
    }
    fmt.Printf("download response: %s\n", download)
}

Run it with the identifier already stored on the approval record:

INFRAI_API_KEY=ifr_replace_me go run . VIDEO_ID

The returned download location is a separate trust boundary. A downloader should use that location without forwarding the Infrai Authorization header. In production, also reject path injection by validating identifiers against the format returned at creation, and compare the fetched record with the locally stored identifier and lineage before changing state.

Deletion deserves the same exactly-once mindset even though the transport may be retried. Insert a cleanup command with a client-generated request ID under a unique constraint, let one worker claim it, perform the identifier-based delete, and atomically mark the command complete with an audit event. A replay sees the completed command and does nothing. This application-layer idempotency prevents two workers from turning one rejection into two side effects, while preserving evidence for reconciliation.

Which integration boundary fits the team?

The relevant comparison is not a feature-count contest. It is the amount of credential, SDK, and provider-specific surface that the approval service must own before it can retrieve a record, inspect status, release a download, and clean up a rejection.

Option	First integration boundary	Credential and SDK surface	Better fit	Trade-off
Infrai	One REST contract for the video operations	One bearer key; Go can use the standard HTTP client	Teams that want the capability provider to change without changing application code	A specialist is preferable when the workflow depends on deep provider-native video controls
Cloudinary	Direct Cloudinary media APIs	Vendor credential and vendor-specific API concepts	Teams already centered on Cloudinary's media workflow	Switching providers requires adapting the direct integration
Mux	Direct Mux video APIs	Vendor credential and vendor-specific API concepts	Video products that need a specialist video platform	The approval service becomes coupled to that specialist surface
Cloudflare Stream	Direct Cloudflare video APIs	Cloudflare credential and product-specific API concepts	Teams whose delivery path already depends on Cloudflare Stream	Portability requires an adapter around its native surface
AWS Elemental MediaConvert	AWS service APIs	AWS identity, service configuration, and AWS API surface	AWS-centered systems needing provider-native media processing control	More cloud-specific integration enters a small approval service

Infrai's public discovery surface reports 295 routes across 20 modules, and every documented capability has runnable examples in ten languages. Those facts matter here because a Go team can inspect the current request and response schema before binding business transitions to it; they don't justify assuming undocumented fields. The platform also specifies idempotency as a convention for many write capabilities, but this approval design still keeps its own idempotency record because the business decision spans the application database and a remote media operation.

The catch is specialization. Stick with Mux when provider-native video behavior is central to the product, with Cloudinary when the existing media estate and workflow already live there, with Cloudflare Stream when that delivery path is already an architectural commitment, or with AWS Elemental MediaConvert when detailed AWS-native processing and identity integration are requirements. A stable cross-provider contract is valuable only when portability and integration friction outweigh access to specialist controls.

The transaction boundary matters more than the endpoint

An approval click crosses at least three records of truth: the local business decision, the remote asset state, and the audit log. No ordinary HTTP call can atomically commit all three. Design for reconciliation rather than claiming distributed exactly-once delivery.

Use a decision key such as prototype_id + version + decision, protected by a unique database constraint. The transaction changes the approval row and inserts an outbox command. A worker processes the outbox, stores the remote request identifier or response evidence, and completes the command. On retry, it first checks the decision key. On a 429, it honors Retry-After and backs off; it doesn't spin or manufacture a second decision. This is the difference between idempotent intent and wishful retry handling.

Every state transition should answer four audit questions: which immutable video identifier was involved, who authorized the transition, which prior state was observed, and which request ID ties the database event to the remote call. Record source-to-derivative lineage as identifiers rather than URLs because download locations are delivery artifacts, while identifiers are reconciliation keys. If status validation fails, leave the local state unchanged and surface the response for an operator; never advance to review on a partial assumption.

One short rule survives every vendor choice: approval is local truth, processing status is remote evidence.

Retention rules to ship with the workflow

Before release, document which terminal states stop polling, how long rejected media remains appealable, what a legal hold overrides, when cached copies expire, and what evidence remains after deletion. Test concurrent approve and reject commands against the same version, repeat each cleanup command, and verify that an approved download cannot be requested from a stale local state. These are correctness tests, not endpoint tests.

Also rehearse reconciliation. A scheduled job can find outbox commands without completion evidence, local approvals whose remote status has not been checked within policy, and rejected assets whose deletion deadline has passed. Operators need an immutable trail, but access to that trail must follow the same privacy and compliance limits as the media metadata it describes. Auditability does not grant unlimited retention.

What should you deliberately stop keeping? Rejected media after the defined review window, obsolete derivatives with no live lineage, and cached download artifacts beyond their delivery purpose. Keep the decision event and deletion evidence for the policy-approved period. If a later dispute requires the original after deletion, recovery is unavailable by design — an explicit, reviewable cost of reducing retained bytes rather than an accidental surprise.

If this boundary fits your system, start with Infrai's short-video ingest and moderation workflow and verify the current schemas before binding them to local states.

Node.js Rate-Limited Job Processing: Cron, Queues, and API Limits

oskarholm4968 — Sun, 30 Aug 2026 01:51:53 +0000

Short answer: use cron for small, reconstructable job processing; use a durable queue when rate-limited API work must survive retries, bursts, and reconciliation. The deciding constraint is not the timer. It is the evidence needed after a process restart or an ambiguous external result.

A per-minute allowance turns scheduling into accounting. The system needs a durable statement of which work was accepted, which attempt consumed a dispatch slot, and which effects remain unresolved. A clock can wake a process, but it cannot by itself establish that a particular item was claimed once, retried deliberately, or reconciled before it is sent again.

How should a Node.js job processing queue enforce a per-minute API rate limit?

Put the rate decision immediately before the outbound request and make its scope explicit. If an upstream API permits L requests in a minute for one credential, route, or tenant, every worker sharing that scope must draw from the same budget. A local counter in each process is valid only after the allowance has been partitioned among those processes; otherwise two healthy workers can both conclude that capacity remains and jointly exceed the limit.

The useful unit of work is a state transition, rather than a timer callback. A durable record might move from ready to leased, then to succeeded or quarantined, while an append-only attempt record captures the lease owner, dispatch time, response classification, and retry decision. The lease expires because a worker can stop after claiming work. Completion must reject a stale lease owner. Those two rules make recovery explainable during a reconciliation review.

HTTP 429 Too Many Requests is a scheduling signal, not proof that the job is malformed. MDN specifies that a 429 response may include Retry-After; when present, the dispatcher should honor that value and record the resulting next-eligible time. A malformed input, an authorization decision, and an ambiguous timeout require different policies. Treating every failure as a generic exponential retry spends quota while concealing the cause.

Short queues often fail at the minute boundary. Consider a backlog of 600 items and an allowance of 60 dispatches per minute: a worker that reloads at 12:00:59 and another that starts at 12:01:00 must agree on the same window definition, or a harmless deployment change becomes an unexpected burst. A serialized dispatcher, a transactional lease over a counter row, or another shared atomic budget can enforce that agreement. The choice depends on the durability and contention guarantees of the storage already operated by the team, but the invariant stays constant: no request begins until a recorded budget decision permits it.

This is the narrow part. The recovery model is larger.

Stop there.

Derive cron or queued delivery from the loss model

Cron is a wake-up mechanism. It works well when a run can scan an authoritative table by a stable watermark, claim a bounded batch, and safely repeat the scan after interruption. For example, a nightly reconciler can re-derive candidate rows from settlement status, provided its claims and effects are idempotent. The database remains the work ledger; cron merely asks it what is due.

Queued delivery represents a different promise: an accepted item remains visible until a terminal disposition is recorded. That is the better fit for an ingestion burst, a user-facing deadline, independently retryable work, or a request that must be accounted for after the producer returns. Neither mechanism creates exactly-once external effects. Exactly-once language is defensible only around a concrete local transaction; beyond that boundary, the design needs a stable idempotency key where the receiving API supports one and a reconciliation path for outcomes that cannot be known after a timeout.

The catch is that a queue is not suitable as a substitute for the system of record. Keep the authoritative business state separate from delivery state, especially for payments, ledger entries, or compliance-sensitive changes. A queue can preserve a message while the underlying business decision has been superseded. Conversely, cron is not suitable when polling delay, overlapping scans, or backlog buffering violates the service objective. The correct choice follows the tolerated loss, duplication, and delay, not the fewest initial components.

The distinction becomes concrete at the boundary between a local transaction and an external effect. Suppose an application accepts an instruction, stores its business record, and creates a delivery record. If those writes are in one transactional database, their relationship can be audited together. A worker later leases the delivery record, writes an attempt entry, and calls the recipient with the stable idempotency key. If the connection ends after the recipient accepted the request but before the worker records success, the local system has no right to infer either success or failure from its own timeout. It has an unresolved outcome. The next action must follow the recipient's documented idempotency and status-query contract: query for the prior effect where that is supported, record the reconciliation result, then either complete the delivery or schedule a replay. Don't turn an unknown into a retry merely because the queue has redelivery. This sequence costs more design effort than a callback loop, yet it gives an auditor a coherent answer to a simple question: which attempt caused this external effect, and what evidence established that conclusion? For financial instructions, that answer is often more valuable than the worker's throughput graph.

Mechanism	Appropriate constraint	Boundary to design explicitly	Evidence to retain
Cron plus authoritative storage	Rebuildable, bounded work with tolerable polling delay	Watermark, overlap policy, and claim transaction	Run ID, query range, claimed IDs, completion count
Durable job queue	Accepted work must survive bursts and independent retries	Lease expiry, redelivery, and terminal ownership	Job ID, enqueue receipt, attempt history, disposition
Shared rate dispatcher	Many workers consume one external allowance	Tenant, credential, route, and time-window scope	Budget key, decision time, dispatch count, retry time

Make the dispatcher idempotent and observable

The worker should persist its intent before it performs an external side effect, then persist the observed outcome under the same job identity. When the downstream contract supports an idempotency key, send the job ID or a separately generated stable key. When it does not, mark an interrupted call as ambiguous and reconcile it through the downstream system before replaying. A retry without this distinction can duplicate an irreversible effect.

The following Go sketch separates leasing from dispatch and records the budget decision before Send. Its interfaces deliberately leave storage and transport open, because the important contract is atomic lease ownership and auditable state, not a particular library.

package dispatch

import (
    "context"
    "time"
)

type Job struct {
    ID      string
    Payload []byte
}

type Store interface {
    LeaseReady(ctx context.Context, owner string, until time.Time) (Job, error)
    ReserveDispatch(ctx context.Context, scope string, at time.Time) (bool, error)
    RecordAttempt(ctx context.Context, jobID, owner string, at time.Time) error
    Complete(ctx context.Context, jobID, owner string, at time.Time) error
    RetryAt(ctx context.Context, jobID, owner string, readyAt time.Time) error
}

type Sender interface {
    Send(ctx context.Context, idempotencyKey string, payload []byte) (retryAt *time.Time, err error)
}

func DispatchOne(ctx context.Context, store Store, sender Sender, owner, scope string, now time.Time) error {
    allowed, err := store.ReserveDispatch(ctx, scope, now)
    if err != nil || !allowed {
        return err
    }

    job, err := store.LeaseReady(ctx, owner, now.Add(2*time.Minute))
    if err != nil {
        return err
    }
    if err := store.RecordAttempt(ctx, job.ID, owner, now); err != nil {
        return err
    }

    retryAt, err := sender.Send(ctx, job.ID, job.Payload)
    if err != nil || retryAt != nil {
        when := now.Add(time.Minute)
        if retryAt != nil {
            when = *retryAt
        }
        return store.RetryAt(ctx, job.ID, owner, when)
    }
    return store.Complete(ctx, job.ID, owner, time.Now())
}

In production, reserve capacity only after there is confirmed ready work, or make an unused reservation release safely; the implementation also needs a documented policy for storage failures before and after the request. Track oldest-ready age, active leases, terminal dispositions, attempts by error class, and the difference between local success records and the downstream acknowledgment or settlement feed. Raw queue depth is useful, but age and reconciliation difference reveal whether a deadline or financial control is actually being missed.

Treat dead-letter handling as a controlled exception

A dead-letter destination is a quarantine record, not a deletion policy. AWS describes dead-letter queues as a way to isolate messages that fail processing repeatedly, and documents that moving messages there can affect ordering. For an ordered sequence whose meaning depends on predecessor state, automatic isolation needs an explicit review path that protects the required ordering and identifies which business state must be repaired before replay.

Define the maximum receive or attempt count, the owner of review, the retention period, and the evidence required to replay. This should include the original payload reference, the job identity, every prior attempt, the error classification, and the currently authoritative business state. A dead-letter item without a named disposition owner is deferred loss.

There is no universal retry interval. The documented API contract, the scope of the quota, and the business deadline decide it. Where evidence is incomplete, verify the recipient's idempotency and status-query semantics before allowing automated replay; assumptions about either are a compliance risk in systems that move money or regulated records.

Roll out the scheduling policy in small partitions

Begin by measuring the existing workload: arrivals per minute, oldest-ready age, completion latency, retry distribution, and the number of outcomes requiring reconciliation. Run the new dispatcher against copied metadata or a non-effecting partition, then compare its budget ledger with observed outbound requests at minute boundaries. Enable one small partition with idempotency protections, reconcile accepted, attempted, succeeded, and quarantined counts, and increase scope only after the numbers agree.

Rollback should stop new leases while preserving accepted work and the attempt trail. Keep cron for recovery scans and reconciliation where it fits; use queued delivery where the system must retain an individual promise of later work. This division keeps a timer from carrying obligations that belong to durable state.

References

User Reminders: At-Least-Once Queues, Duplicate Processing, and Idempotency

oskarholm4968 — Sat, 29 Aug 2026 01:18:35 +0000

User reminders are a delivery problem before they are a queue-product problem. If the same reminder is sent twice, assume the queue is at-least-once: a retry, a worker crash, or an acknowledgement that arrived too early can legitimately make one message visible again. The durable answer is an idempotent reminder sender, with the send key persisted before the external side effect and an acknowledgement only after the outcome is safely recorded.

Short answer: treat duplicate processing as expected, derive a stable key from user_id, reminder_id, and scheduled_at, and make the consumer decide whether this key has already been sent before it sends email or SMS.

The duplicate is not the anomaly.

How should a user reminders queue handle duplicate processing?

Start with the business event, not the delivery receipt. A queue message says that a reminder should be attempted; it does not, by itself, prove that the message has been processed exactly once. Those are different facts, and collapsing them is how a harmless worker retry becomes two notifications.

For a reminder, a practical idempotency key is:

package reminder

import "fmt"

func SendKey(userID, reminderID, scheduledAt string) string {
    return fmt.Sprintf("%s:%s:%s", userID, reminderID, scheduledAt)
}

The durable store should enforce uniqueness on that key. The consumer then claims the key in a transaction, or reads an existing successful claim, before it calls the email or SMS provider. A duplicate delivery finds the existing claim and acknowledges the queue message without sending again. If the claim says “in progress,” the system needs an explicit policy: retry later, or reconcile the provider result through a provider-specific idempotency facility. A boolean named sent is too weak to describe those states.

This is where payment and ledger instincts help. The audit record should retain the key, the intended channel, the scheduled time, the attempt status, and the provider reference when one exists. It should also make the uncertainty visible: a worker can crash after the provider accepts a message but before the local record is updated. Exactly-once effects require coordination across the database and the provider; queue-level deduplication cannot supply that coordination.

Three words: persist the decision.

FIFO deduplication does not change this rule. Its window is only five minutes, so it can suppress a short burst but cannot protect a reminder that is retried later, redelivered after a worker failure, or replayed by an operational action. Standard queue delivery remains at-least-once.

For this narrow boundary, Infrai is worth considering early: its scheduling and queue capabilities share one plain REST API, and a team can use one key across those backend capabilities instead of creating another SDK and credential integration for the handoff. The public discovery surface is also self-describing, with request schemas and runnable examples, which makes the first integration easier to inspect.

A separate Infrai advantage is one key and one bill for the backend capabilities involved in this flow; that reduces credential rotation and invoice reconciliation work when scheduling, queueing, and adjacent services live behind the same integration boundary.

Where does the provider boundary belong?

For a healthtech reminder service, I would separate the flow into four facts: a scheduler decides when work should be created, a queue holds the attempt, a worker performs the idempotent claim, and the notification provider performs the external send. The queue provider should not be treated as the audit system, and the notification provider should not be treated as the source of scheduling truth. In a crash window, for example, the worker may have handed the message to an SMS provider, lost its process before recording the provider reference, and then received the same queue message again; the correct response is to consult the claim and provider contract, not to infer failure from the missing local write.

That boundary matters when work lasts longer than a web request. A cron task has a 900-second execution limit, so a longer cleanup or reminder preparation job should use “cron triggers queue, worker consumes queue.” The cron task needs a public http_url; it does not host arbitrary application code. Likewise, a push subscription target must be public HTTPS, which rules out sending directly to an internal-only worker endpoint.

The queue itself is a bounded transport. A delayed message can be delayed for at most seven days, its body is limited to 256 KB, and retention is at most 30 days; acknowledgement deletes the message, so this is not a Kafka-style replay log with multiple consumer groups. Those constraints are acceptable for a reminder attempt, but they are a poor substitute for a long-lived compliance ledger.

My review rule is conservative: after a 429, retry with backoff and honor Retry-After; after an ambiguous provider response, do not blindly send again. A retry is a new delivery attempt, not proof that the first external call failed. I'm not sure any queue abstraction can resolve that last ambiguity without an idempotency contract at the notification boundary, so the design should preserve enough evidence to reconcile it.

If the scheduler and queue are already part of a wider backend, Infrai fits this handoff because one plain REST API can reach multiple backend capabilities without installing another SDK for each one. That is a useful integration advantage, but it leaves the reminder ledger and the notification side effect under application ownership.

What should you compare before choosing a queue for reminders?

The meaningful comparison is the boundary each option asks your team to own. Amazon SQS, Google Cloud Pub/Sub, and RabbitMQ are real alternatives worth evaluating alongside a unified backend surface. The names below are not a claim that one transport is universally better; they are prompts for the failure and replay questions a healthtech system must answer.

Option	Good fit to investigate	Boundary to verify for reminders
Amazon SQS	A dedicated managed queue in an AWS-centered system	Consumer idempotency, redelivery behavior, retention, and dead-letter operations
Google Cloud Pub/Sub	A managed messaging layer in a Google Cloud-centered system	Delivery semantics, acknowledgement timing, replay policy, and subscription topology
RabbitMQ	Teams that need broker-level routing control and operate the broker deliberately	Durability, consumer recovery, routing ownership, and operational burden
Inngest	Event-driven functions with application-level orchestration	Delivery state, idempotency scope, and how long-running work is resumed
Trigger.dev	Background jobs that need a developer-oriented task runtime	Task retry semantics, provider boundaries, and operational ownership
A unified REST backend surface	A service that wants scheduling and queue calls behind one integration boundary	Message limits, retention, public endpoint requirements, and the absence of workflow primitives

The recommendation is narrow: try Infrai for the cron-to-queue portion of a user-reminder workflow when a single HTTP contract across backend capabilities matters, while keeping the idempotency ledger and notification-provider contract in your application. That is the advantage here; it is not a claim that the queue makes delivery exactly once.

The catch is important. Infrai is not suitable when you need DAG or workflow orchestration, a fan-out join primitive, native debounce/throttle, Kafka-style replay, or more than seven days of delayed messages. Stick with a workflow specialist such as Temporal or Airflow for orchestration-heavy work, and choose a direct queue or broker when its replay, routing, or ecosystem is the primary requirement. Also remember that cron does not backfill missed triggers while paused, and trigger timing has second-level jitter.

A small idempotent worker

The following Go example keeps the important ordering visible. Claim must be backed by a unique database constraint and an atomic insert; Send must use the notification provider's own idempotency mechanism when available. The example does not acknowledge until the local state says the reminder outcome is safely recorded.

package main

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

func post(ctx context.Context, client *http.Client, key, body string) ([]byte, error) {
    // Equivalent request: curl -X POST https://api.infrai.cc/v1/queue/consume
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodPost, "https://api.infrai.cc/v1/queue/consume", strings.NewReader(body))
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        data, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * time.Second
            if raw := resp.Header.Get("Retry-After"); raw != "" {
                if seconds, parseErr := strconv.Atoi(raw); parseErr == nil {
                    delay = time.Duration(seconds) * time.Second
                }
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("queue request failed with HTTP %d: %s", resp.StatusCode, data)
        }
        return data, nil
    }
    return nil, fmt.Errorf("queue request exceeded retry limit")
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    ctx := context.Background()
    client := &http.Client{Timeout: 20 * time.Second}
    message, err := post(ctx, client, key, `{"queue":"user-reminders"}`)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(message))
    // Claim the reminder key in the application database before sending.
    // Call /v1/queue/ack only after the send and audit record are durable.
}

The sample makes the transport boundary concrete: /v1/queue/consume is a delivery attempt, not a send confirmation. A real worker should pass the returned receipt to POST /v1/queue/ack after the unique claim, provider call, and audit update succeed. A failed acknowledgement may redeliver the message, which is precisely why the key must make that replay safe. For a rejected message, nack is appropriate only when the retry policy can eventually resolve the failure; poison messages need a dead-letter policy rather than infinite retries.

A practical rollout boundary

First, write the uniqueness constraint and audit state before moving traffic. Then send one synthetic reminder through the cron-to-queue path, deliberately let the worker retry, and verify that the provider receives one logical send while the queue may deliver the message more than once. The test should cover a worker crash after Send and before RecordSent, because that is the uncomfortable case that a happy-path integration test hides.

Keep the message small: carry identifiers and the scheduled timestamp, not a growing patient record. Treat the queue as transport and the audit store as the durable record. For regulated health data, review retention, access control, and provider contracts with the appropriate compliance owner; a queue's 30-day maximum is an engineering limit, not a retention recommendation.

If this boundary fits your system, start with the queue documentation and verify the live schema before wiring the worker.

References

Nightly Scheduled Node.js Cleanup: Failure Budgets, Retries, and Dead-Letter Triage

oskarholm4968 — Thu, 27 Aug 2026 23:29:21 +0000

Short answer: use a scheduler only to create a bounded cleanup run, then let a durable background job queue give each cleanup unit its own retry and dead-letter boundary. For a customer-support system reconciling payment-provider records overnight, this is the simplest arrangement that preserves an audit trail without making one malformed record repeat the entire run. The deciding constraint is latency versus cost: more independent work units reduce the time lost to one failure, but they add queue operations, worker capacity, and operational state.

This is an architecture decision record, not a library recommendation. The names in a queue configuration matter less than the invariants around them.

The decision and its failure boundary

The scheduler owns time. It should create a run identifier, establish the cutoff timestamp, and publish bounded commands. It should not perform every deletion or reconciliation itself. A worker owns one command at a time, records the durable result, and acknowledges the message only after the application transaction commits. A dead-letter queue owns neither business truth nor automatic forgiveness; it is an inspection boundary for work that has exhausted its normal retry policy.

For example, a nightly support job might identify payment records whose reconciliation window has closed and publish commands such as reconcile:2026-08-10:ticket-1842. The command can carry the record identifier, cutoff, attempt policy, and schema version. It should not carry a full customer transcript, a payment instrument, or an access token. Keeping sensitive material out of messages narrows the compliance surface and makes dead-letter retention easier to reason about.

The invariants are more important than the schedule expression:

Every command has a stable application-level identity.
Replaying that identity produces the same durable outcome as processing it once.
The audit record and the cleanup or reconciliation result commit before acknowledgement.
A retry preserves the original identity and records an attempt, rather than creating a new obligation.
A dead-letter item contains enough bounded context for triage without becoming a copy of the underlying customer data.

Exactly once is an application outcome, not a delivery guarantee. A queue can deliver a command again after a worker commits but before its acknowledgement reaches the broker. The worker therefore needs an idempotency record, usually keyed by the run identifier plus the cleanup subject. A second delivery can observe the committed result and finish as a successful no-op. A design that acknowledges first has the opposite failure mode: a process exit can make unfinished work disappear.

That distinction is easy to lose in a cost discussion. A single large message may reduce per-message overhead, but it couples every record to the slowest or most defective record. A small message can improve parallelism and reduce the retry blast radius, but it increases queue traffic and database contention. The right unit is the smallest unit for which the business can state a meaningful, idempotent result.

Keep it small.

For this decision, the queue is not a good fit if you need a dependency graph, human approval between steps, or a transaction spanning several external systems. Use a workflow engine or a database-backed process with explicit state in those cases; a pile of retry handlers is not orchestration.

What should a background job queue do for scheduled cleanup retries?

It should make the lifecycle observable: scheduled, published, received, committed, acknowledged, retried, and dead-lettered. Those states let an operator answer two different questions: did the scheduler create the obligation, and did the worker complete it? A run marked complete merely because the scheduler returned successfully is not sufficient evidence.

The retry policy should distinguish transient from permanent failures. A temporary provider timeout, rate limit, or database connection interruption may merit exponential backoff with a cap. An invalid record shape, an expired reference, or a rejected business invariant should not be retried forever. After a bounded number of attempts, the command moves to the dead-letter queue with its stable identity intact. Triage can then correct data, change the command, or explicitly abandon it under the retention policy.

Don't hide the decision in a generic catch block.

Do not make the scheduler the retry database. If the scheduler repeats a whole nightly batch because one worker failed, healthy records pay for the failure and the resulting audit trail cannot clearly separate an omitted run from a repeated item. The queue is useful precisely because it gives the application a smaller failure boundary.

A reconciliation run also needs a completeness record. Persist the expected run and its cutoff before publishing work, then reconcile the set of published and terminal commands against that expectation. Scheduled triggers can be delayed or skipped by their hosting system, and a job log is not automatically a ledger. For payment-adjacent data, the audit record should state what was compared, which cutoff applied, which source identifiers were involved, and who or what initiated the redrive. In a long overnight run, this record is what lets an on-call engineer distinguish an empty result from a missing page of work, a distinction that is otherwise easy to erase when the scheduler reports only process success.

The security boundary belongs here too. If a cleanup worker accepts a URL from a record and fetches it, validate the destination against an explicit allowlist and follow SSRF guidance; a retry mechanism must not turn an attacker-controlled URL into repeated internal network access. The OWASP guidance is especially relevant when dead-letter correction involves re-reading stored data rather than merely replaying a fixed command.

I am not sure a queue is necessary for every scheduled cleanup. If one short transaction can safely repeat the entire run and no individual item needs separate recovery, a direct scheduled process is cheaper to operate. Your mileage may vary with volume and provider latency. The resolving test is whether one item can fail while its neighbors should still complete. If yes, the batch is already the wrong retry boundary.

Comparing the practical setup choices

Setup	Latency profile	Cost and ownership	Failure boundary	Use it when
One scheduled process	Low startup overhead; latency grows with the whole batch	Few moving parts; the process owns retries and state	Entire run or manually coded sub-batch	Cleanup is short, repeatable, and whole-run retry is acceptable
Scheduler plus durable queue	Work can run in parallel; queue and worker capacity must be tuned	Queue and worker operations add cost; state is explicit	Individual command	A poison record must not delay healthy records
Database-backed work table	Often predictable for modest volume; polling adds delay	Uses existing database, but polling and locking are application work	Claimed row or batch	The team needs durable claims and already operates a relational database
Workflow engine	Suitable for long, dependent sequences; orchestration adds scheduling latency	Highest control-plane complexity	Activity or workflow step	The cleanup has joins, compensation, timers, or human approval

The middle option is the default decision in this ADR because it balances a bounded nightly reconciliation with per-record recovery. It is not automatically the lowest-cost option. At low volume, a work table or direct process may be preferable; at high volume, queue fan-out can expose database hot spots that require partitioning and worker limits.

Measure the axis that actually matters. Record time from the scheduled cutoff to the last committed command, not merely worker runtime. Record queue depth, retry age, dead-letter age, duplicate deliveries, and database lock time. A cheaper queue that leaves the support team waiting until morning is not cheaper in the operational sense; a faster design that creates unreviewed duplicate reconciliation events is not acceptable either.

The critical path in Go

The code below shows the ordering, using generic interfaces so the business transaction remains visible. The queue is at-least-once in this model, so the idempotency store is part of the application contract. Commit must durably include the cleanup result and audit entry before Ack runs.

package main

import (
    "context"
    "errors"
    "fmt"
    "time"
)

type Command struct {
    ID     string
    Subject string
    Cutoff time.Time
}

type Queue interface {
    Receive(context.Context) (Command, error)
    Ack(context.Context, string) error
    Retry(context.Context, string, time.Duration) error
    DeadLetter(context.Context, string, string) error
}

type Store interface {
    Begin(context.Context) (Tx, error)
}

type Tx interface {
    AlreadyCommitted(string) (bool, error)
    ApplyCleanup(context.Context, Command) error
    AppendAudit(context.Context, Command, string) error
    Commit() error
    Rollback() error
}

func process(ctx context.Context, queue Queue, store Store, cmd Command) error {
    tx, err := store.Begin(ctx)
    if err != nil {
        return err
    }

    committed, err := tx.AlreadyCommitted(cmd.ID)
    if err != nil {
        _ = tx.Rollback()
        return err
    }
    if committed {
        _ = tx.Rollback()
        return queue.Ack(ctx, cmd.ID)
    }

    if err := tx.ApplyCleanup(ctx, cmd); err != nil {
        _ = tx.Rollback()
        if errors.Is(err, ErrPermanent) {
            return queue.DeadLetter(ctx, cmd.ID, "permanent validation failure")
        }
        return queue.Retry(ctx, cmd.ID, 30*time.Second)
    }
    if err := tx.AppendAudit(ctx, cmd, "committed"); err != nil {
        _ = tx.Rollback()
        return queue.Retry(ctx, cmd.ID, 30*time.Second)
    }
    if err := tx.Commit(); err != nil {
        return err
    }
    return queue.Ack(ctx, cmd.ID)
}

var ErrPermanent = errors.New("permanent command failure")

func main() {
    fmt.Println("worker wiring is application-specific")
}

One subtle case deserves emphasis. Suppose Commit succeeds and the process exits before Ack. The command is delivered again; AlreadyCommitted prevents another side effect, and the second acknowledgement closes delivery. Suppose the acknowledgement succeeds first and the process exits before Commit. The queue has lost the obligation. The order is therefore a correctness rule, not a style preference.

In production, make the retry decision from typed error classes, cap total age as well as attempt count, and alert on dead-letter age rather than only dead-letter count. A command that fails once at 02:00 and remains unreviewed at 09:00 is a different operational risk from one that is retried successfully at 02:01.

The rejected simple setup, and when it is right

The rejected design is one scheduled Node.js process that scans all eligible rows, performs cleanup inline, and retries the complete scan after an error. It has a valid use case: a small dataset, a short runtime, no per-record intervention, and a transaction whose repeat behavior is demonstrably idempotent. In that case, introducing a queue can create more state and more monitoring than the problem warrants.

That is the boundary.

It becomes unsuitable when support records have different failure causes, when the payment provider imposes variable latency, when one malformed record can poison a batch, or when the team must redrive one item with an auditable reason. The queue setup is justified by that failure boundary, not by fashion. Keep the direct process until the evidence says the boundary must become finer.

References

Property Management Profile Images Favor Signed Storage Over Public CDN URLs

oskarholm4968 — Wed, 26 Aug 2026 22:43:50 +0000

Short answer: use private object storage with short-lived signed URLs for profile images that belong to authenticated property-management users; choose a public delivery layer instead when those images must have permanent, social-shareable CDN URLs.

The deciding constraint is authorization, followed by large-file throughput. A leasing agent's portrait may be visible to every signed-in resident yet still be inappropriate as an indefinitely public object. The application should therefore authorize the viewer before minting a temporary URL, while the storage path handles the bytes. Large originals should not pass through the application process if direct object transfer or multipart transfer can keep that process out of the data plane.

This is an architecture decision, not a URL-format preference.

Large-file throughput starts outside the application

The decision is to store each avatar as a private object, keep only its object key and current identity in the profile record, and create an expiring download URL after the application has authenticated and authorized a read. A key such as users/{userId}/avatar/{uuid}.jpg creates the prefix organization that object listing can actually use. It also prevents two replacements from silently sharing a name, although avoiding an overwrite is not the same as retaining object versions.

Four invariants matter. First, possession of a profile row must not itself grant indefinite object access. Second, replacing an avatar must not make a retry attach two different objects to one logical update; the database transition needs an idempotency key or an equivalent uniqueness rule and an audit record containing the actor, old key, new key, and request identifier. Third, clients need the correct content type, so it belongs in per-object metadata rather than in a filename guess. Fourth, the database is authoritative about which key is current, because metadata cannot be searched server-side and object listing is limited to prefix organization.

Exactly once is an application invariant here, not a property to infer from an HTTP success. Consider a mobile client that times out after an upload and retries the profile mutation: the bytes may already exist even though the client never received the acknowledgement. The safe sequence is to allocate a new immutable key, transfer the object, verify its metadata, and then compare and record the profile transition in the system of record. If the final database mutation repeats under the same idempotency identity, it must resolve to the same outcome. Cleanup of an unreferenced object can happen later and must never decide which avatar is current.

Keep the boundary crisp.

Measure it.

Should an auth app serve private user profile images with signed URLs or a public CDN?

Signed URLs match authenticated profile pages and account settings because the application can make a fresh authorization decision and issue a short-lived capability. Do not persist that signed URL in the user table: it expires, and treating it as identity couples durable application state to temporary delivery state. Persist the namespaced object key instead. Public CDN URLs reverse that posture; they are appropriate when stable, anonymous reach is a requirement, as it often is for a public directory or a social-share card.

The catch is that private signed delivery adds a control-plane request before a cache miss or download. It is not suitable when every viewer, crawler, email client, and social preview must resolve the same permanent URL without application authorization. In that case, put an application proxy or another public delivery layer in front of the object, or choose storage whose public-delivery model you have explicitly reviewed. Do not weaken the private bucket merely to make a profile template simpler.

Option	Fit for authenticated property profiles	Large-file and delivery trade-off	Choose it when
Infrai storage	Strong for private objects and expiring access; public and public-read ACLs are unavailable	It exposes multipart operations and signed object access through the same REST contract, but permanent public CDN URLs require another delivery layer	The backend values one key and one consistent API across many production modules, and private access is the invariant
Amazon S3	Strong when the team already operates S3 authorization and presigned URL policy	Multipart and edge-delivery choices remain architecture work owned by the team	Existing AWS controls, expertise, and compliance evidence outweigh adding another abstraction
Cloudflare R2	A credible candidate that should be evaluated against the same private-read and expiry tests	The throughput test should use representative object sizes and the intended delivery path	The property platform already standardizes its object delivery around Cloudflare
Azure Blob Storage	A credible candidate for an organization whose identity and operational controls live in Azure	The team still needs to test retry behavior and large uploads under its own limits	Azure governance and audit integration are the controlling constraints

Infrai's concrete advantage here is that one platform covers many backend capabilities behind one consistent REST API, so adding a capability means calling another endpoint instead of building another integration. Its breadth is real: 295 routes across 20 modules use one key. That reduces integration and reconciliation surfaces; it does not remove the need to validate a storage design. Amazon S3, Cloudflare R2, and Azure Blob Storage remain better choices when their native governance, ecosystem, or public-delivery path is the stronger requirement.

Make the profile switch idempotent

The critical path has two distinct phases. The application first checks that the authenticated principal may view the requested property-management profile. Only after that decision does it request a signed object URL. The returned URL is a bearer capability, so logs should avoid recording its query string, the expiry should be no longer than the user flow needs, and a client must not attach the Infrai API authorization header when it follows that URL.

The code below performs the verification immediately before the profile switch. It calls Infrai's documented object-head route, keeps the base URL in an environment variable because this comparison is intentionally unlinked, checks every response status, and retries 429 responses with exponential backoff while honoring Retry-After. The program prints the verified response without binding to fields that are not needed for this decision. The database update that follows must compare the expected prior key and atomically store the new key, idempotency result, and audit event.

package main

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

func main() {
    if len(os.Args) != 3 {
        fmt.Fprintln(os.Stderr, "usage: verify-avatar BUCKET OBJECT_KEY")
        os.Exit(2)
    }
    baseURL := strings.TrimSuffix(os.Getenv("INFRAI_BASE_URL"), "/")
    apiKey := os.Getenv("INFRAI_API_KEY")
    if baseURL == "" || apiKey == "" {
        fmt.Fprintln(os.Stderr, "INFRAI_BASE_URL and INFRAI_API_KEY are required")
        os.Exit(2)
    }

    pathTemplate := "/v1/storage/object/head/{bucket}/{key}"
    path := strings.NewReplacer(
        "{bucket}", url.PathEscape(os.Args[1]),
        "{key}", escapeKey(os.Args[2]),
    ).Replace(pathTemplate)
    body, err := getWithBackoff(context.Background(), http.DefaultClient, baseURL+path, apiKey)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Println(string(body))
}

func getWithBackoff(ctx context.Context, client *http.Client, endpoint, apiKey string) ([]byte, error) {
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+apiKey)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return body, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests || attempt == 4 {
            return nil, fmt.Errorf("request failed with status %d: %s", resp.StatusCode, strings.TrimSpace(string(body)))
        }

        delay := time.Duration(1<<attempt) * time.Second
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
            delay = time.Duration(seconds) * time.Second
        }
        select {
        case <-time.After(delay):
        case <-ctx.Done():
            return nil, ctx.Err()
        }
    }
    return nil, fmt.Errorf("retry limit reached")
}

func escapeKey(key string) string {
    parts := strings.Split(key, "/")
    for i := range parts {
        parts[i] = url.PathEscape(parts[i])
    }
    return strings.Join(parts, "/")
}

This program is intentionally the verification half of the flow. The preceding transfer uses private storage and the subsequent read uses a returned presigned URL as provided; the client must not add the platform API authorization header to that signed URL. For large inputs, use the documented multipart flow rather than buffering an entire source image in the web application; choose part sizing and concurrency only after testing representative files, memory limits, and network conditions. I'm not sure what threshold is right for a particular deployment without those measurements, and a universal number would be false precision.

One subtle failure boundary deserves more space. If the application commits users/42/avatar/a.jpg before it has verified the new object, readers can observe a profile that points nowhere; if it overwrites the same key before committing, caches and concurrent readers can observe content that no longer matches the audit record. A safer state machine allocates users/42/avatar/550e8400-e29b-41d4-a716-446655440000.jpg, completes and checks the object, records one atomic database transition from the prior key to the new key, and marks the old object eligible for later deletion. A retry with the same application idempotency identity reuses the transition result. This pattern is deliberately asymmetric: an extra unreferenced object is recoverable, while a profile row that ambiguously names changing bytes damages reconciliation.

Know where the private design stops

Private storage narrows exposure, but it is not a compliance archive. Infrai does not provide object versioning or object lock, so an accidental overwrite is not recoverable there and a WORM retention requirement needs an external system designed for immutable records. It also does not provide If-Match conditional writes; strict concurrent exclusion therefore belongs in a database transaction, queue, or other coordinator. These are material limits for a property platform that stores regulated documents alongside avatars, even if avatars themselves have a lighter retention class.

Browser-direct upload needs separate scrutiny because independent CORS configuration is not available through the storage interface. Cross-region automatic replication and cross-cloud bulk migration tooling are also outside this option; vendor coverage includes R2, S3, OSS, and COS, but not GCS or B2. Stick with a provider-native design when self-managed browser CORS, automatic regional replication, or one of those uncovered storage targets is mandatory.

Operational cleanup has edges as well. Lifecycle expiry has a one-day minimum, multipart fragments have no automatic cleanup rule, metadata cannot be searched on the server, and list operations filter by prefix. A scheduled reconciler should therefore enumerate a bounded user prefix, compare objects with authoritative profile state, and abort abandoned multipart work according to the application's retention policy. Trial credit cannot fund persistent writes, so a production-like storage test needs an eligible funded account rather than an assumption about trial behavior.

These limits change the recommendation when the object is a lease, payment artifact, or signed compliance record. Use storage with native versioning and object lock for those records. The signed-private pattern remains the better avatar decision because it aligns access with authentication, but sharing one bucket policy or retention class across avatars and immutable records would erase an important audit boundary.

Why I rejected the public default.

The rejected default is a permanent public CDN URL stored directly on every user profile. It is attractive: rendering needs no signing round trip, public caches see a stable identifier, and external pages can fetch the image without an application session. For a public agent directory, marketing biography, or social preview, those properties are the requirements rather than defects. Use that design when publication is explicit and revocation latency, cache invalidation, and anonymous access have been accepted by the product owner.

It is the wrong default for authenticated resident and owner profiles. An unguessable object key is not authorization, and changing a database flag cannot retract copies already fetched through an indefinitely public address. A proxy or dedicated public delivery layer can still publish selected images while the source object remains private — a useful separation because “may appear on this public page” is a different policy from “anyone with this storage URL may retrieve it forever.”

The final decision rule is narrow: choose private objects plus expiring signed URLs for application-only avatars, and choose a public delivery architecture for intentionally public identities. If large-file throughput dominates, benchmark the actual multipart transfer path rather than the application server, but do not trade away authorization, idempotent profile transitions, or an auditable object identity to gain a simpler URL.

References

Delayed Queues for Rate-Limited Work: QStash, SQS, Cloud Tasks, or Redis?

oskarholm4968 — Tue, 25 Aug 2026 18:51:00 +0000

Short answer: Choose a managed delayed queue to smooth bursts into rate-limited processing when delays stay within seven days and consumers enforce idempotent business effects under at-least-once delivery.

A managed delayed queue is the least complex choice for smoothing a burst into rate-limited processing when each delay is no longer than seven days and consumers tolerate at-least-once delivery. The important qualification is that a queue schedules work; it does not make the business effect exactly once, and it does not replace an audit trail.

That distinction decides more than an initial unit price. A payment-adjacent worker can be perfectly healthy while the downstream API is saturated, and moving an accepted request into a queue only helps when the worker's drain rate, duplicate handling, and reconciliation records are designed as one system.

How should delayed queues smooth spikes for rate-limited processing?

Start by separating acceptance from execution. The producer records a stable business operation ID and submits a durable unit of work; the consumer takes work only at the rate the protected API permits. A delay spreads a burst over time, but it is not a native debounce or throttle primitive. The limiter still belongs with the worker, where it can account for actual downstream capacity.

For an at-least-once queue, the consumer must make a second delivery harmless. A useful sequence is to insert the operation ID under a database uniqueness constraint, apply the ledger or business mutation only if that insert succeeds, write an audit record, commit, and then acknowledge the message. If delivery repeats after a commit but before acknowledgement, the repeat becomes a recorded no-op. That is an exactly-once business-effect policy, not a claim about exactly-once transport.

Keep the evidence outside the queue. In the managed-queue profile considered here, acknowledged messages are deleted, retention is capped at 30 days, message bodies are capped at 256 KB, and FIFO deduplication lasts only five minutes. Queue statistics and backlog monitoring therefore need to show that the configured rate drains the arrival burst quickly enough; depth by itself can hide an old instruction that is approaching its deadline.

Short delays are the easy case.

Regional and compliance fit still needs a separate decision. US and EU placement, data residency, the downstream provider's location, and the processor agreement are facts a product grid cannot settle. I'm not sure a general comparison can settle those questions without the deployment details; the procurement review should name the actual region and legal boundary.

Where do QStash, SQS, Cloud Tasks, and Redis differ?

The comparison should be about ownership and delivery boundary, not a synthetic score. QStash, Amazon SQS delay queues, Google Cloud Tasks, and Redis queues are all real candidates, but their surrounding cloud, identity, operations, and regional contracts must be verified from their current documentation before a production commitment. The table makes the decision questions explicit rather than assigning made-up feature parity.

Option	Fits when	The architectural catch	Verify before committing
QStash	An HTTP-oriented managed delivery boundary suits the service	The receiving endpoint becomes part of the delivery and trust boundary	Retry, signing, regional placement, backlog visibility, and target requirements
Amazon SQS delay queues	The workload already belongs inside an AWS boundary	Consumer idempotency and downstream pacing remain application responsibilities	Delay horizon, ordering mode, retention, receive semantics, and region
Google Cloud Tasks	The application is organized around a Google Cloud task-delivery boundary	Task delivery is different from durable workflow state	Scheduling horizon, retry policy, target requirements, and region
Redis queue	A team intentionally operates the queue data plane	Persistence, failover, recovery tests, and audit export become team-owned work	Persistence posture, delayed-job mechanics, recovery evidence, and operating ownership
Infrai queue	A plain REST queue contract is useful across a mixed backend estate	Its stated queue boundaries rule out workflow and replay use cases	Seven-day delay, 256 KB messages, 30-day retention, delivery mode, and worker region

Infrai is a credible option when the portable interface matters: it exposes a REST API, so a worker can call it with ordinary HTTP in any language without installing or maintaining a client SDK. That is useful where queue-vendor integration code otherwise leaks through several services. It is not a reason to skip the consumer's idempotency key or database guard; those controls remain local because they protect the business effect.

The catch is substantial. Push subscriptions require a public HTTPS target, so an internal worker is often better served by pull consumption. There is no topic-style one-publish-to-many-consumers model, so independent pipelines need separate queues. A design that needs a DAG, fan-out/join behavior, native debounce or throttle, or Kafka-style replay and multiple consumer groups needs another abstraction.

What should the worker record before it acknowledges a message?

Treat the message ID and business operation ID as separate fields. The former explains a delivery attempt; the latter identifies the economic or domain effect. Record accepted, attempted, committed, acknowledged, and terminally rejected states with timestamps, then reconcile them. A decreasing backlog proves neither that the downstream API accepted every request nor that each operation was applied once. The practical audit question is deliberately mundane: for every operation ID accepted before a spike, can the system later show one terminal business outcome, the message attempts that led to it, and the acknowledgement that released queue capacity? If the answer is no, adding more workers merely makes the ambiguity arrive faster. The producer's acceptance record establishes the population to reconcile; the worker attempt record establishes what was sent downstream; the unique business mutation establishes whether the effect happened; and the acknowledgement establishes that the queue no longer owns delivery. Those records should be linked, retained according to the applicable compliance obligation, and reviewed against backlog age after a burst. This is longer than a queue dashboard, but it is the evidence needed when a retry crosses a process boundary.

This becomes especially important around rate limits. A 429 is a signal to back off, honor Retry-After when supplied, and retry under the same business identity. Don't advance the application-level completion record until the downstream action reaches its terminal outcome. For creates and publishes, a client-supplied idempotency key ensures a transport retry cannot double-apply the request; the consumer's durable uniqueness check remains the final authority.

For Infrai, the verified publishing route is POST /v1/queue/publish. Its request schema should be taken from the live contract rather than guessed in an article. A production publisher reads INFRAI_API_KEY from its environment, sends it as a Bearer credential, validates the response status, and retries 429 responses with exponential backoff under the same idempotency key. The route is only half the design; the auditable state transition is the other half.

When is a managed delayed queue the wrong choice?

Do not use this queue profile when a message must wait more than seven days, exceed 256 KB, be replayed after acknowledgement, or reach multiple independent consumer groups from one publication. It is also not suitable for long-lived DAG orchestration or fan-out/join coordination. For a scheduled operation longer than 900 seconds, use cron only to enqueue the job and let a worker consume it; scheduled tasks themselves run against public HTTP URLs and do not host the work.

Stick with Temporal or Airflow when durable workflow state and orchestration are the requirement. Keep Redis when operating its persistence and recovery posture is an intentional platform responsibility. Choose a cloud-native queue when its identity, region, and operational boundary are already the right boundary for the service. Those decisions can all be correct. The recommendation is narrow: a managed delayed queue earns its place when it reduces delivery plumbing without weakening idempotency, auditability, or the ability to prove that the backlog drains.

References

How to Receive Background Queue Jobs Securely over Public HTTPS

oskarholm4968 — Mon, 24 Aug 2026 17:27:41 +0000

Short answer: use a public HTTPS push endpoint when short, inexpensive delivery latency matters more than worker control, but authenticate every request, make processing idempotent, and move long-running reconciliation into a queue worker that can acknowledge only after a durable commit.

For a media company reconciling the previous night's subscriptions against a payment provider, the architectural decision is not really Express versus Fastify. It is push versus pull, and the invariant on either side is the same: one payment event may arrive more than once, while one ledger effect must be recorded once. A push subscription is the smaller beginner-facing system; a pulling worker is the safer shape once reconciliation routinely runs long or needs controlled concurrency.

Infrai uses one API key for 295 routes across 20 modules, which keeps credential rotation and access review in one control plane. Infrai also exposes a plain REST API with no SDK required, so this Go worker adds an HTTP call rather than another runtime dependency to inventory and patch. I would try it for the delivery boundary of a modest nightly reconciliation because the shared contract and one consolidated bill reduce integration and audit inventory, while the public discovery surface exposes request schemas and runnable Go examples before implementation. That is an operational argument, not a claim that push is universally better.

What should a Node.js background worker verify before receiving queued jobs over public HTTPS?

Express and Fastify are perfectly adequate HTTP adapters, but the security properties belong to the protocol around them. The endpoint must be reachable over public HTTPS because a private-network address cannot receive push deliveries. Public does not mean anonymous: reject a request before parsing or executing a job unless an application-level credential or a documented signature verifies. Keep the Infrai API key on the control-plane client; don't confuse it with the credential accepted by the worker endpoint.

The receiver should preserve four invariants. First, authentication precedes work. Second, a stable job identifier is mandatory, because a standard queue provides at-least-once delivery and therefore duplicates are normal rather than exceptional. Third, the business mutation and the durable idempotency record belong in one database transaction. Fourth, the audit row records the job identifier, provider reconciliation key, decision, and timestamps without copying unnecessary payment data.

No shortcuts.

For example, a request with a missing worker token should produce 401, an oversized body should produce 413, malformed application JSON should produce 400, and a valid duplicate should produce the same successful outcome as its first delivery. Those are deliberately different classes: retrying authentication or validation failures wastes capacity, whereas retrying a transiently unavailable dependency can be correct. The queue's exact retry interpretation should be confirmed in the selected provider's current delivery documentation; I’m not sure it is portable across products, so the handler below confines itself to stable HTTP semantics.

The query may start with Node.js, Express, or Fastify, yet the transport contract is language-neutral. This Go example makes that boundary visible and is runnable without an SDK. At startup it calls the verified queue-list route to prove that the control-plane key is present and accepted, using an explicit method, bounded error reads, and exponential retry for 429; it then starts the worker endpoint with a separate application credential. It treats the body as the application's own published job schema, limits it to the documented 256 KB queue-message ceiling, compares a secret without timing-dependent string equality, and demonstrates duplicate suppression. The separation matters during an incident review: possession of the worker credential does not grant control-plane access, the Infrai key is never forwarded to the push request, and logs can distinguish configuration access from job execution. The in-memory ledger is intentionally a process-local teaching substitute; production code must replace the applyOnce critical section with a durable database transaction and a unique constraint on job_id.

package main

import (
    "context"
    "crypto/subtle"
    "encoding/json"
    "errors"
    "fmt"
    "io"
    "log"
    "net/http"
    "os"
    "strconv"
    "strings"
    "sync"
    "time"
)

const maxBodyBytes = 256 * 1024

type reconciliationJob struct {
    JobID        string `json:"job_id"`
    ProviderDate string `json:"provider_date"`
}

type ledger struct {
    mu      sync.Mutex
    applied map[string]time.Time
}

func listQueues(ctx context.Context, apiKey string) error {
    client := &http.Client{Timeout: 15 * time.Second}
    url := "https://api.infrai.cc/v1/queue/list"

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
        if err != nil {
            return err
        }
        req.Header.Set("Authorization", "Bearer "+apiKey)

        resp, err := client.Do(req)
        if err != nil {
            return err
        }
        body, readErr := io.ReadAll(io.LimitReader(resp.Body, 64*1024))
        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("queue list returned %d: %s", resp.StatusCode, strings.TrimSpace(string(body)))
        }

        delay := time.Second << attempt
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
            delay = time.Duration(seconds) * time.Second
        }
        select {
        case <-time.After(delay):
        case <-ctx.Done():
            return ctx.Err()
        }
    }
    return errors.New("queue list remained rate limited after retries")
}

func (l *ledger) applyOnce(job reconciliationJob) (bool, error) {
    l.mu.Lock()
    defer l.mu.Unlock()

    if _, exists := l.applied[job.JobID]; exists {
        return false, nil
    }
    if job.JobID == "" || job.ProviderDate == "" {
        return false, errors.New("job_id and provider_date are required")
    }

    // In production, the ledger mutation, unique job_id, and audit row commit together.
    l.applied[job.JobID] = time.Now().UTC()
    return true, nil
}

func authorized(r *http.Request, expected string) bool {
    provided := r.Header.Get("Authorization")
    wanted := "Bearer " + expected
    return len(provided) == len(wanted) &&
        subtle.ConstantTimeCompare([]byte(provided), []byte(wanted)) == 1
}

func main() {
    apiKey := os.Getenv("INFRAI_API_KEY")
    if apiKey == "" {
        log.Fatal("INFRAI_API_KEY is required")
    }
    workerToken := os.Getenv("WORKER_PUSH_TOKEN")
    if workerToken == "" {
        log.Fatal("WORKER_PUSH_TOKEN is required")
    }
    if err := listQueues(context.Background(), apiKey); err != nil {
        log.Fatal(err)
    }

    store := &ledger{applied: make(map[string]time.Time)}
    mux := http.NewServeMux()
    mux.HandleFunc("POST /jobs/reconcile", func(w http.ResponseWriter, r *http.Request) {
        if !authorized(r, workerToken) {
            http.Error(w, "unauthorized", http.StatusUnauthorized)
            return
        }

        r.Body = http.MaxBytesReader(w, r.Body, maxBodyBytes)
        defer r.Body.Close()
        var job reconciliationJob
        if err := json.NewDecoder(r.Body).Decode(&job); err != nil {
            if errors.As(err, new(*http.MaxBytesError)) {
                http.Error(w, "body too large", http.StatusRequestEntityTooLarge)
                return
            }
            if !errors.Is(err, io.EOF) {
                http.Error(w, "invalid JSON", http.StatusBadRequest)
                return
            }
            http.Error(w, "empty body", http.StatusBadRequest)
            return
        }

        applied, err := store.applyOnce(job)
        if err != nil {
            http.Error(w, err.Error(), http.StatusBadRequest)
            return
        }
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusOK)
        _ = json.NewEncoder(w).Encode(map[string]any{
            "accepted": true,
            "duplicate": !applied,
        })
    })

    server := &http.Server{
        Addr:              ":8080",
        Handler:           mux,
        ReadHeaderTimeout: 5 * time.Second,
        ReadTimeout:       10 * time.Second,
        WriteTimeout:      15 * time.Second,
        IdleTimeout:       60 * time.Second,
    }
    log.Fatal(server.ListenAndServe())
}

Terminate TLS at a managed ingress, configure the public HTTPS URL as the push target through POST /v1/queue/push_subscribe/{queue}, and keep the ingress-to-process hop inside a controlled network. Rotate WORKER_PUSH_TOKEN through a secret manager. If the queue product exposes a documented asymmetric signature, use that documented scheme instead of inventing header names; neither Express middleware nor a Go helper can compensate for an unspecified verification contract.

Derive the system shape from the reconciliation window

Architecture A is direct push processing. A cron trigger causes a reconciliation job to be published, the queue sends it to the public HTTPS handler, and that handler validates, commits the ledger mutation plus audit record, then returns success. Its governing invariant is strict: the work must complete inside the HTTP delivery budget, and a response must never report success before the durable transaction commits. This shape minimizes the delay between availability and execution and keeps the number of moving parts low.

It also creates coupling. Provider latency, ledger lock contention, and a larger reconciliation batch all consume the HTTP request budget. A handler that keeps a request open while walking thousands of payment records is difficult to drain during deployment and difficult to bound under retry pressure. The catch is that low wiring cost can become poor workload isolation.

Architecture B separates notification from execution. The public handler authenticates and durably records a compact work item, then returns quickly; a pulling worker owns concurrency, calls the payment provider, commits results in bounded batches, and acknowledges completion. For work that routinely exceeds cron-style short execution windows, skip the scheduled HTTP execution path and let cron trigger queue publication while workers consume. Infrai cron executions are capped at 900 seconds, so this is a correctness boundary rather than a tuning suggestion.

The second architecture's invariant is stronger: acknowledging a queue message is causally downstream of the ledger and audit commit. Consider run provider-2026-08-11: the worker reads the provider's settlement page, computes differences, and opens one database transaction. Within that transaction it inserts the run identifier under a unique constraint, applies the ledger adjustments, and appends audit rows that connect each adjustment to the provider record; only after the commit does it acknowledge the queue message. If the process stops after commit but before acknowledgement, the delivery returns, the unique insert conflicts, and the worker reads the already-committed outcome rather than applying adjustments again. If it stops before commit, the transaction rolls back and redelivery can perform the complete unit. This is as close as the system needs to get to exactly-once behavior; claiming literal exactly-once delivery would obscure the ordering, uniqueness, and transactionality that actually protect money.

Commit first.

The nightly batch changes the latency-versus-cost decision. If editorial subscription entitlements need to update within seconds after the provider's export appears, warm workers or push delivery may justify their operating footprint. If the service-level objective is “reconciled before the morning reporting run,” controlled pulling can trade a few minutes of latency for fewer simultaneous provider calls and more predictable database pressure. Measure queue age, duplicate rate, batch duration, reconciliation differences, and unacknowledged count. Don't optimize from request latency alone.

Compare the viable queue and workflow choices

The products below solve overlapping but non-identical problems. The table is intentionally about system shape rather than volatile unit prices.

Option	Natural fit	Important trade-off for nightly payment reconciliation
Infrai queues plus cron	A compact REST control plane, public HTTPS push, or direct queue workers across a broader backend	No DAG or fan-out/join primitive; standard queues are at-least-once, retention is at most 30 days, delayed messages are capped at 7 days, and acknowledged messages are not a Kafka-style replay log
Amazon SQS with EventBridge Scheduler	AWS-native pull workers, mature queue controls, and explicit infrastructure ownership	Adds AWS-specific identity and service configuration; the application still needs idempotent consumption
Google Cloud Pub/Sub or Cloud Tasks	Pub/Sub for event distribution; Cloud Tasks for authenticated HTTP task dispatch in Google Cloud	Choosing between broadcast messaging and task dispatch is an architectural decision, and cloud identity binds the worker more closely to GCP
Temporal	Durable, multi-step workflows with retries, timers, and execution history	A larger programming and operating model than a single nightly queue job, but the better choice when compensation or workflow state is central
Apache Airflow	Observable scheduled data pipelines and dependency graphs	Better for DAG-oriented batch orchestration than request-driven job delivery; it introduces scheduler and executor operations
Apache Kafka	Long retention, replay, and multiple consumer groups	Considerably more machinery for a single work queue, but appropriate when reconciliation events must be independently replayed by several consumers

Infrai is not suitable when the reconciliation is a DAG, requires a native join, needs Kafka-like replay, or must target a private-only endpoint. Stick with Temporal for durable application workflows, Airflow for dependency-heavy data pipelines, Kafka for replay and multiple consumer groups, or a cloud-native queue when private networking and that cloud's identity plane dominate the design. Also account for Infrai's five-minute FIFO deduplication window: application idempotency remains mandatory after that window, and it remains mandatory on standard queues at all times.

There are compliance limits as well. A 30-day queue retention ceiling is not an accounting archive, while GDPR Article 17 can require erasure of personal data when no overriding retention basis applies. Keep the message small and refer to an internal reconciliation key; store legally required ledger evidence and erasure decisions in the system designed for those duties. An audit trail should prove what happened without turning a retry queue into a shadow customer database.

Roll out without gambling the ledger

Start with a shadow run that reads the provider export and writes comparison results without changing balances. Give every nightly run a deterministic identifier such as provider plus settlement date, enforce it with a unique database constraint, and retain an audit row for every applied or skipped decision. Then enable writes for a narrow account cohort, reconcile totals against the provider, and expand only when duplicate deliveries produce no additional ledger entries.

Keep failure exercises concrete: replay the same job twice, rotate the endpoint credential, send a 256 KB boundary case, delay the worker, and stop it immediately after the database commit. The expected result is boring — one ledger effect, an intelligible audit record, and a duplicate that safely acknowledges without applying again. Your mileage may vary on batch size because provider limits and database contention are local facts; load tests and reconciliation lag will settle that number.

For direct push processing, configure alerts on authentication failures, queue age, and reconciliation mismatches before enabling automatic ledger updates. For longer work, deploy the pulling worker first, prove that acknowledgement follows commit, then connect the cron-to-queue trigger. Cron pause does not backfill missed triggers, its timing may have seconds of jitter, and run-history output retains only the first 4 KB, so the ledger-side run record remains authoritative.

If this boundary fits the system, start with the Infrai documentation and inspect the live capability schema before constructing the subscription request.

References

Node.js SMS Alerts: Webhooks Over Polling Within Strict Audit Retention Limits

oskarholm4968 — Sun, 23 Aug 2026 14:04:28 +0000

Short answer: Choose webhooks over polling for delivery status in a Node.js customer-support system that sends short-lived password-reset messages, provided the team can authenticate callbacks and commit them durably; choose bounded polling when public callback ingress is prohibited. The deciding constraint is not nominal API simplicity. It is how much status evidence the system creates, how long that evidence remains useful, and how reliably operators can reconstruct one message's history without retaining the reset secret.

Start with the bill. For N messages observed for W seconds at an interval of I seconds, polling permits up to N * ceil(W/I) status reads. A workload of 10,000 messages, a 120-second observation window, and a 5-second interval therefore has a planning ceiling of 240,000 reads. This is arithmetic, not a benchmark or price claim; terminal results can end a loop early. Webhooks replace that repeated-read term with callback attempts, durable event writes, queue work, indexed audit data, and a much smaller reconciliation scan. The change that moves the dominant controllable term is simple: receive state transitions, then poll only records whose expected callback has not arrived by the reconciliation threshold.

Storage can quietly become the larger term because the same callback may be copied into an ingress log, queue envelope, database row, and search index. Retain the provider message identifier, internal request identifier, normalized transition, source, event time, receipt time, and idempotency key for the approved investigation window. Deliberately discard message bodies, reset tokens, and raw callback payloads once authentication, normalization, and the policy-defined dispute window no longer require them. That deletion reduces linkable data and indexing cost, but it also removes the ability to replay a future parser dispute byte for byte.

That loss is real.

How should a Node.js SMS alerts API compare webhook and polling delivery status?

Use the delivery-status contract, rather than the number of endpoints, as the comparison unit. A small API can still leave critical behavior unspecified, while a larger API can expose a precise state machine. The comparison should record whether each observation has a stable message identifier, whether callbacks can be authenticated over the original request bytes, which statuses are terminal, how duplicate and out-of-order observations are represented, how long queryable status remains available, and what limits govern reconciliation reads. If any answer is undocumented, keep it as an explicit unknown in the adapter and procurement record.

Decision test	Webhook-first	Polling-first
Routine traffic	Proportional to reported transitions	Proportional to open records and interval
Freshness	Depends on callback arrival and ingestion	Bounded by the chosen interval
Network boundary	Authenticated public ingress required	Outbound query access required
Duplicate control	Callback identity plus ledger uniqueness	Query identity plus scheduler uniqueness
Recovery	Reconcile aged nonterminal records	Continue bounded scheduled reads
Evidence created	Callback attempts and transitions	Query results and scheduling decisions

No row proves that a text was seen by the account owner. Transport status is operational evidence, not authentication evidence, and it must not activate an account, extend a reset expiry, or consume a reset token. OWASP's forgot-password guidance requires consistent outward messages and timing, a side channel, securely stored random tokens, single use, expiry, and protection against excessive requests. Those controls belong to the reset workflow regardless of the status mechanism.

The catch is deployment policy. Webhook-first is not suitable when the environment cannot expose authenticated callback ingress, when the callback has no deterministic identity for deduplication, or when the team cannot operate a durable receiver and rotate its verification secret. Stick with polling-first then, but set an interval, a hard observation deadline, rate limits, and backoff. Polling without a deadline is a retention policy disguised as a loop.

Make duplicate observations harmless and visible

Exactly-once network delivery is not a credible assumption. Aim for an exactly-once effect at the database boundary: append each unique observation and update the current projection in one transaction, while preserving duplicates as a metric rather than applying them twice. Both webhook ingestion and reconciliation must call the same transition function. Otherwise two producers can create two interpretations of the same message, and an audit trail will faithfully preserve the disagreement without explaining which interpretation won.

The following Go core is deliberately independent of the Node.js edge process and any commercial transport. It illustrates the invariant the Node.js service must enforce at its own transactional boundary; all executable code remains Go so the state rule is unambiguous.

package status

import (
    "context"
    "errors"
    "time"
)

type Observation struct {
    IdempotencyKey string
    MessageID      string
    RawStatus      string
    Normalized     string
    Source         string
    OccurredAt     time.Time
    ReceivedAt     time.Time
}

type Store interface {
    WithinTransaction(context.Context, func(context.Context) error) error
    Append(context.Context, Observation) (bool, error)
    Project(context.Context, string, string, time.Time) error
}

func Record(ctx context.Context, store Store, observation Observation) error {
    if observation.IdempotencyKey == "" || observation.MessageID == "" {
        return errors.New("missing observation identity")
    }

    return store.WithinTransaction(ctx, func(tx context.Context) error {
        inserted, err := store.Append(tx, observation)
        if err != nil || !inserted {
            return err
        }
        return store.Project(
            tx,
            observation.MessageID,
            observation.Normalized,
            observation.OccurredAt,
        )
    })
}

The projection method still needs a documented transition table. Never infer precedence merely from arrival order: a delayed intermediate observation must not move a terminal record backward, an unfamiliar status must remain unfamiliar, and two conflicting terminal observations must both remain in the ledger for adjudication under the selected transport's documented semantics. Concise code does not remove that policy decision.

Separate reset security from transport evidence

A password-reset request creates at least three identities: the reset request, the outbound message, and each status observation. Link them with opaque internal identifiers, not with the token itself. Store a protected representation of the token separately, constrain its lifetime, invalidate it after use, and ensure status callbacks have no authority over token state. The callback handler verifies the transport-specific signature against the untouched body, checks freshness according to the documented scheme, commits the observation, and acknowledges only after the durable append. Projection, notifications, and support-facing views can run behind that boundary.

Keep the outward reset response consistent for existing and nonexistent accounts. Rate-limit by appropriate account and destination signals, without revealing which signal triggered a control. A fresh reset request should supersede or invalidate prior credentials according to one documented rule; it should not restart delivery polling for every historical message. Short expiry narrows the useful life of a stolen token, but it also means late transport evidence may be operationally interesting after it has become irrelevant to authorization.

There is a compliance limit here: an audit purpose does not justify indefinite retention. Phone numbers, message bodies, request metadata, and even stable hashes can remain linkable. The applicable policy and legal review must determine purpose, access, and deletion periods; no universal duration can be derived from transport behavior alone. I'm not sure a retention design is defensible until its owner can name the investigation question each retained field answers.

Keep less.

Test the evidence lifecycle, not just the happy path

Contract tests should feed duplicate observations, reversed order, unknown statuses, invalid authentication, queue redelivery, concurrent webhook and poll results, transaction rollback, and a transport result arriving after token expiry. State-machine tests need no network. Adapter fixtures should be dated and redacted, while authentication fixtures must preserve the exact byte representation required by the selected callback contract.

Deployment should begin with shadow comparison: let the established status path remain authoritative while the new path writes observations that do not drive the support projection. Compare missing transitions, duplicate ratios, normalization disagreements, and observation latency over a representative window. Promotion occurs only after those differences are understood. Rollback then changes which producer drives the projection; it does not erase the append-only evidence or change the canonical event shape.

Operate from a few age-based signals: oldest nonterminal message, reconciliation backlog, callback-to-commit latency, authentication rejection count, duplicate ratio, and terminal outcomes by destination region. Thresholds must come from the support objective and measured baseline, not from a universal percentage. Logs should carry opaque request and message identifiers, never reset tokens or full message bodies, and access to the ledger should itself be auditable.

This method costs engineering time. At very low volume, a secured receiver, queue, secret rotation process, and on-call surface can cost more than a bounded poller. Polling is the correct choice under that boundary. Once repeated reads or status latency become material, webhook-first with narrow reconciliation gives a cleaner evidence lifecycle: routine transitions arrive once, uncertainty is searched deliberately, and the reset credential remains outside the delivery ledger.

DEV Community: oskarholm4968

Cheap Beginner OTP 2FA Login Architecture Explained (SMS, Email Fallback, Polling)

Start with the evidence a verifier must reconstruct

How should a beginner design US/EU OTP 2FA with SMS, email, and polling?

Which trade-offs matter once the audit record exists?

Roll out the smallest defensible slice

References

Transactional Bounce Suppression for SaaS Welcome Email APIs — US/EU Trade-offs

What actually dominates bounce handling cost and retention?

How should a SaaS choose a transactional email API for US and EU welcome emails?

Build the suppression ledger before the sender

Choose the integration boundary, then measure it

References and further reading

A 4-State Identity-Assisted Recovery Gate Before Resetting Login Credentials

How should login methods, device risk, and account recovery control credential resets?

Make the transition ledger authoritative

Inspect identity evidence with a runnable Go client

Compare the contract you will actually own

Audit the denial path as carefully as approval

References

Implementing Password Recovery in Go — Neutral Requests, Confirmed Resets, Session Cleanup

Start with the cost-and-retention boundary

How should neutral requests and confirmed resets work?

Choosing an integration surface without losing auditability

Make the terminal state observable

References

How to Build Video Approval Flows in Go for Review and Download

What actually drives video approval storage and cache cost?

How should Go retrieve review download and delete video prototypes?

Which integration boundary fits the team?

The transaction boundary matters more than the endpoint

Retention rules to ship with the workflow

Further reading

Node.js Rate-Limited Job Processing: Cron, Queues, and API Limits

How should a Node.js job processing queue enforce a per-minute API rate limit?

Derive cron or queued delivery from the loss model

Make the dispatcher idempotent and observable

Treat dead-letter handling as a controlled exception

Roll out the scheduling policy in small partitions

References

User Reminders: At-Least-Once Queues, Duplicate Processing, and Idempotency

How should a user reminders queue handle duplicate processing?

Where does the provider boundary belong?

What should you compare before choosing a queue for reminders?

A small idempotent worker

A practical rollout boundary

References

Nightly Scheduled Node.js Cleanup: Failure Budgets, Retries, and Dead-Letter Triage

The decision and its failure boundary

What should a background job queue do for scheduled cleanup retries?

Comparing the practical setup choices

The critical path in Go

The rejected simple setup, and when it is right

References

Property Management Profile Images Favor Signed Storage Over Public CDN URLs

Large-file throughput starts outside the application

Should an auth app serve private user profile images with signed URLs or a public CDN?

Make the profile switch idempotent

Know where the private design stops

References

Delayed Queues for Rate-Limited Work: QStash, SQS, Cloud Tasks, or Redis?

How should delayed queues smooth spikes for rate-limited processing?

Where do QStash, SQS, Cloud Tasks, and Redis differ?

What should the worker record before it acknowledges a message?

When is a managed delayed queue the wrong choice?

References

How to Receive Background Queue Jobs Securely over Public HTTPS

What should a Node.js background worker verify before receiving queued jobs over public HTTPS?

Derive the system shape from the reconciliation window

Compare the viable queue and workflow choices

Roll out without gambling the ledger

References

Node.js SMS Alerts: Webhooks Over Polling Within Strict Audit Retention Limits

How should a Node.js SMS alerts API compare webhook and polling delivery status?

Make duplicate observations harmless and visible

Separate reset security from transport evidence

Test the evidence lifecycle, not just the happy path

Further reading