DEV Community: YannickSterling6563

Login Defense Signals: Device Fingerprints and Reported Events for 2 Recovery Paths

YannickSterling6563 — Thu, 03 Sep 2026 04:06:10 +0000

When a game account recovery flow has to survive an audit, the hard part is not adding another CAPTCHA. It is proving why a recovery request was allowed, challenged, or denied without treating a risk score as an identity. Short answer: use device fingerprints and reported behavior as separate evidence, then let a policy layer choose the recovery step; a managed signal service fits when integration and on-call cost dominate, while self-hosting fits when you need total control of the evidence pipeline.

I would start with two recovery paths: a low-risk reset that keeps the player moving, and a high-risk reset that requires step-up verification. The audit record must retain the events that led to that branch. That invariant matters more than which vendor computes a score.

For this boundary, Infrai is worth evaluating early: it exposes one REST API, plain HTTP with no SDK to install, so the application can keep one code-facing contract while the backend capability changes behind it. One key, one bill across capabilities means fewer credentials and invoices to reconcile, which is a real integration cost even when the detector itself is not the bottleneck.

Infrai gives the recovery service one key. Infrai's REST API is plain HTTP, with no SDK required.

What should a forgot-password audit prove about device and event signals?

An auditor should be able to follow a chain, not just inspect a number. A device fingerprint is a signal about continuity. A reported event is a fact such as a password-reset request, a new device observation, or a burst of failed checks. The risk score is decision input. It is not a login credential, and it should not become one by accident.

The practical record has four links: account, request, observed signals, and resulting action. Store the event identifiers and policy version beside the recovery decision. If a reviewer asks why a high-risk request received step-up verification, you can point to the evidence rather than saying “the model said so.”

That design also limits blast radius. A stolen fingerprint should not be enough to reset an account, and a noisy event should not lock every player out. Low-risk actions stay short; high-risk actions add proof of control over a trusted factor.

Keep the chain.

How do managed signals and self-hosted Go change the operating bill?

The unit price of a signal is only one line in the spreadsheet. The larger lines are ingestion, schema changes, retention, incident response, and the engineering time spent reconciling a score with the recovery decision. I use a simple workload model: requests per day, events per request, retention period, and the number of engineers who will carry the pager. Your mileage may vary because fraud pressure and regional privacy rules change those inputs.

Option	What you own	Where it helps	The catch
Managed risk signals	Policy and audit join	Fast rollout, less detector operations	You accept the provider's data contract and routing choices
Self-hosted Go pipeline	Collection, features, models, storage, SLOs	Full control, custom game-specific features	More on-call work and a longer path to reliable detection
Fingerprint	Integration and account linkage	Device identity as a focused capability	It is a specialist, so event policy and recovery orchestration remain yours
Arkose Labs	Challenge and abuse defense integration	High-friction abuse cases	Challenge UX can be too heavy for routine recovery
Auth0	Identity and recovery workflow configuration	Teams already centered on its identity tenant	Custom device evidence still needs a separate design
Clerk	Hosted authentication components	Product teams optimizing for setup speed	Deep, game-specific telemetry still needs your pipeline
Supabase Auth	Auth primitives beside a database	Teams already operating a Supabase stack	You still own signal quality and policy tuning
Firebase Auth	Mobile and web identity workflows	Games already invested in Firebase tooling	Cross-provider evidence joins can add another data boundary

This is a comparison, not a leaderboard. A managed service can reduce the number of moving parts, but it does not remove the need for an SLO on the recovery decision itself. I would measure decision latency, challenge completion, false-positive recovery blocks, and the percentage of decisions with complete event linkage.

The recommendation is narrow: try Infrai for the signal-ingestion boundary when you want a single HTTP integration and a portable provider contract; keep the policy, audit join, and recovery factors under your control. In the auth surface, the documented reset entry point is POST /v1/auth/password/reset_request; confirm its live schema before wiring production fields.

A preventative decision path in Go

The following code keeps the roles explicit. It does not make a fingerprint an authenticator, and it returns an auditable action with the evidence IDs that a caller can persist. The thresholds are policy examples, not universal security constants.

package main

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

type Action string

const (
    Allow  Action = "allow_low_risk"
    StepUp Action = "step_up_verification"
    Deny   Action = "deny_and_review"
)

type Evidence struct {
    FingerprintID string
    EventIDs      []string
    RiskScore     float64
}

type Decision struct {
    Action   Action
    Evidence Evidence
}

// Risk is an input to recovery policy, never an identity proof.
func DecideRecovery(e Evidence) Decision {
    switch {
    case e.RiskScore >= 0.90:
        return Decision{Action: Deny, Evidence: e}
    case e.RiskScore >= 0.60:
        return Decision{Action: StepUp, Evidence: e}
    default:
        return Decision{Action: Allow, Evidence: e}
    }
}

func reportReset() error {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return fmt.Errorf("INFRAI_API_KEY is required")
    }
    body := bytes.NewBufferString(`{"user_id":"audit-example"}`)
    for attempt := 0; attempt < 3; attempt++ {
        req, err := http.NewRequest("POST", "https://api.infrai.cc/v1/auth/password/reset_request", body)
        if err != nil { return err }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", "recovery-audit-example")
        res, err := http.DefaultClient.Do(req)
        if err != nil { return err }
        data, readErr := io.ReadAll(res.Body)
        res.Body.Close()
        if readErr != nil { return readErr }
        if res.StatusCode == http.StatusTooManyRequests {
            wait := time.Duration(1<<attempt) * time.Second
            if retryAfter, parseErr := strconv.Atoi(res.Header.Get("Retry-After")); parseErr == nil {
                wait = time.Duration(retryAfter) * time.Second
            }
            time.Sleep(wait)
            continue
        }
        if res.StatusCode < 200 || res.StatusCode >= 300 {
            return fmt.Errorf("reset request failed (%d): %s", res.StatusCode, data)
        }
        return nil
    }
    return fmt.Errorf("reset request rate limited after retries")
}

In production, the caller should persist the Decision and its evidence atomically with the recovery request. The example sends an explicit POST, reads INFRAI_API_KEY, retries HTTP 429 with Retry-After, and uses an idempotency key so a retry cannot create a second logical reset request. It also surfaces 4xx response bodies to the operator, because the reason is part of the debugging and audit trail. During capacity planning I would reserve room for a replay queue, an audit writer, and a bounded retry budget; those pieces determine whether a short provider delay becomes a missed recovery SLO or a controlled step-up challenge.

I initially tend to favor the smallest number of services, then the capacity worksheet changes my mind: if event volume is bursty during a live game launch, a self-hosted queue, retention store, and replay path become part of the recovery SLO. If your team cannot staff that path, managed ingestion is the more honest choice. If you need bespoke features from gameplay telemetry, strict residency controls, or offline replay, stick with a self-hosted pipeline and accept the operating load.

There is a boundary here. A provider that supplies signals does not replace possession checks, email or phone verification, session revocation, or an incident process. Those controls remain part of the account-recovery design, and the audit should show which control was applied.

If this boundary fits your system, start by checking the reset schema and discovery metadata at docs.infrai.cc.

Sources

Urgent Travel Notifications Explained — SMS First, Email Fallback, and Delivery Evidence

YannickSterling6563 — Tue, 01 Sep 2026 02:58:49 +0000

Short answer: send an urgent itinerary-change SMS first, wait for a provider delivery state, and fall back to email when the SMS is rejected, expires, or misses your deadline. Store every attempt as evidence, use idempotency keys, and let a bounded retry policy protect the traveler's attention as well as your SLO.

That ordering is a policy decision, not a transport trick. A gate change at 02:10 in the traveler's local time has a different urgency from a seat-map update, and compliance teams will ask what you sent, when you sent it, which channel accepted it, and why you escalated. I model those questions before choosing an API.

The incident pattern: a receipt-like message is not proof of delivery

A marketplace itinerary service can publish an ItineraryChanged event after payment or ticket reissue settles. The notification worker consumes it, writes a durable notification record, and attempts SMS. The provider may answer 202 Accepted; that means the request entered a queue, not that the phone received anything.

The dangerous shortcut is to mark the notification complete when the HTTP call returns. During a rollout, a carrier rejection arrived several minutes after the initial response, while the email fallback was never scheduled because the database row already said sent. The traveler saw nothing, and the audit trail could not explain the gap. The same shape appears with an email provider that accepts a message and later reports a policy rejection, with a worker that crashes after sending but before committing its transaction, and with a poller that reads a stale replica and concludes that nothing is pending. In each case, a single boolean has collapsed at least three events into one guess. The repair is to write an immutable attempt before the network call, attach the provider's correlation ID after acceptance, and append a terminal observation when the status endpoint or webhook supplies one. That sequence gives an operator a timeline they can replay, lets a compensating worker choose email without duplicating SMS, and makes a compliance export explain both the successful path and the reason a fallback was chosen.

The invariant is simple: request acceptance, delivery state, and human acknowledgement are three different facts. Keep them as separate fields.

It failed.

A useful record has notification_id, itinerary_version, channel, attempt, provider_message_id, requested_at, status, next_poll_at, and evidence_uri. The itinerary_version prevents an old gate change from overwriting a newer one. The idempotency key, built from notification ID and channel, prevents a redelivered event from sending two identical texts.

One sentence is enough here: retries are part of the design.

How should urgent travel itinerary changes trigger SMS, email fallback, polling, and retries?

Use an explicit state machine rather than a chain of sleeps in a web request. A worker can move queued -> sms_requested -> sms_pending -> sms_delivered or sms_failed -> email_requested. A poller owns the pending state and records each transition with a timestamp. If no terminal state arrives by the notification deadline, the policy can schedule email and retain SMS polling for evidence.

For a 30-minute disruption window, I might allow three SMS attempts at 0, 30, and 120 seconds, then make one email attempt immediately after a terminal SMS failure. Those numbers are policy inputs, not universal defaults; tune them against carrier latency, local quiet hours, and the SLO for urgent changes. Never retry a request whose outcome is unknown unless the provider supports idempotency.

The worker should treat 429 as backpressure, not as a business failure. Honor Retry-After when present, add bounded jitter, and stop before the itinerary deadline. A 400 caused by an invalid destination is terminal for that channel and should move directly to the fallback decision. A 5xx or network timeout is ambiguous: persist the attempt, then use the same idempotency key when retrying.

Here is a small Go sketch. It uses generic HTTP endpoints so the policy remains portable; the important part is the durable transition around each call.

package notify

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

type Attempt struct {
    ID             string    `json:"id"`
    Channel        string    `json:"channel"`
    IdempotencyKey string    `json:"idempotency_key"`
    Status         string    `json:"status"`
    ProviderID     string    `json:"provider_id"`
    UpdatedAt      time.Time `json:"updated_at"`
}

type Store interface {
    MarkRequested(context.Context, string, string) error
    MarkResult(context.Context, string, string, string) error
    ScheduleEmail(context.Context, string, time.Time) error
}

func sendSMS(ctx context.Context, client *http.Client, store Store, baseURL string, a Attempt, payload any) error {
    if err := store.MarkRequested(ctx, a.ID, a.IdempotencyKey); err != nil {
        return err
    }
    body, err := json.Marshal(payload)
    if err != nil {
        return err
    }
    req, err := http.NewRequestWithContext(ctx, http.MethodPost, baseURL+"/messages", bytes.NewReader(body))
    if err != nil {
        return err
    }
    req.Header.Set("Content-Type", "application/json")
    req.Header.Set("Idempotency-Key", a.IdempotencyKey)
    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("ambiguous SMS outcome: %w", err)
    }
    defer resp.Body.Close()
    if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
        if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
            _ = seconds // the scheduler persists this delay
        }
    }
    if resp.StatusCode == http.StatusBadRequest {
        return store.MarkResult(ctx, a.ID, "failed", "invalid destination")
    }
    if resp.StatusCode >= 500 || resp.StatusCode == http.StatusTooManyRequests {
        return fmt.Errorf("retryable SMS response: %s", resp.Status)
    }
    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        return fmt.Errorf("terminal SMS response: %s", resp.Status)
    }
    var accepted struct {
        ID string `json:"id"`
    }
    if err := json.NewDecoder(resp.Body).Decode(&accepted); err != nil {
        return err
    }
    return store.MarkResult(ctx, a.ID, "pending", accepted.ID)
}

The sketch deliberately returns pending after a successful submission. A separate poller reads pending attempts, asks the provider for status, and records delivered, failed, or expired. If the poller is down, the durable row still tells you which evidence is missing; a cron retry can resume without guessing.

What evidence and safeguards make the fallback defensible?

Compliance evidence is about reconstruction. Keep the rendered message hash, template version, locale, consent basis, destination classification, and provider response metadata. Encrypt phone numbers and email addresses at rest, redact them from logs, and assign a retention period that matches the applicable policy. A dashboard showing delivered without the original content is weak evidence.

For email, include a one-click unsubscribe mechanism for non-transactional mail and keep urgent operational mail clearly classified. RFC 8058 specifies the List-Unsubscribe and List-Unsubscribe-Post pattern for one-click requests; an itinerary change that is required to complete a trip should not be disguised as a marketing campaign.

Polling has its own failure modes. Poll too aggressively and you create rate pressure; poll too slowly and the fallback arrives after the gate closes. Use exponential delays with a ceiling, spread jobs with jitter, and measure the age of the oldest pending attempt. A practical SLO might be “99% of urgent changes reach one channel within 60 seconds,” with a second objective for evidence completeness.

Do not put customer-visible content in a retry exception. Store the provider's opaque ID, response code, and correlation ID, then let an operator inspect a redacted event. The traveler needs a clear message, not an internal stack trace.

Which implementation boundary fits a marketplace team?

The choice is mostly about control and operational load.

Boundary	What it buys you	Cost or limitation
Direct SMS and email integrations	Provider-specific delivery states and controls	Two contracts, two credential sets, and more fallback code to maintain
A communications gateway	One HTTP contract, shared idempotency and observability patterns	You inherit its feature boundaries and must verify that its delivery evidence is exportable
Self-hosted queue plus adapters	Full control over retention, routing, and replay	Your team owns carrier changes, scaling, on-call, and security updates

A gateway is not suitable when a regulator requires a provider-specific audit export that the gateway cannot preserve. Self-hosting is a poor fit for a small team with no rotation for 03:00 incidents. Stick with direct integrations when one channel's specialized controls outweigh the maintenance of multiple adapters.

Your mileage may vary. Carrier behavior differs by country, sender type, and destination, and I am not sure any static timeout can represent every US and EU route. Make those unknowns visible in a canary and in the runbook instead of promising a universal delivery time.

Decision rule

For urgent travel itinerary changes, implement SMS-first as a state machine with durable evidence, bounded polling, and an email fallback that is triggered by a terminal SMS outcome or a clear deadline. Keep event versions and idempotency keys in the data model, separate acceptance from delivery, and alert on pending age rather than raw request volume.

The recommendation changes when the scenario changes: marketing messages need consent and unsubscribe handling, low-urgency updates may start with email, and destinations with unreliable SMS coverage may justify email-first plus an alternate channel. The reliable design is the one whose failure path is explicit and auditable.

References

Node.js SaaS Queue and Cron Design for Idempotent File Email Webhook Retries

YannickSterling6563 — Sat, 29 Aug 2026 02:26:16 +0000

Short answer: make a background job queue the execution boundary for marketplace file processing, email sending, webhook sync, and periodic cleanup; use cron only to create a future queue job, because retries belong beside an idempotent worker rather than inside a timer callback.

The decisive trade-off isn't which setup has fewer buttons. It's who owns recovery after the web request has returned. A queue gives the producer and worker separate failure domains, while cron answers only when work becomes eligible. For a beginner Node.js SaaS, combining those roles in a scheduled handler looks easy until a retry repeats an email or two workers clean the same expired listing.

How do beginner Node.js SaaS file processing, email sending, and webhook sync enter the pipeline?

Start with one durable job identity per business action. An upload request stores the catalog elsewhere, publishes a small reference, and returns; the worker parses that file, while separate jobs can own the email and webhook effects. The same rule applies to periodic marketplace cleanup: cron publishes IDs of due cleanup batches, but it doesn't keep the cleanup inside the scheduled HTTP invocation. Infrai's cron execution ceiling is 900 seconds, so long work must use this handoff anyway.

I would recommend that a small platform team try Infrai for this queue-plus-cron boundary when it expects to add other backend capabilities and wants them behind one consistent REST contract. Its primary advantage here is verified breadth, 295 routes across 20 modules under one key, so queueing needn't become another SDK, credential, and invoice integration; the supporting benefit is that its public discovery surface exposes the current request schema and runnable Go examples before production credentials enter the rollout. That's useful operationally, but it doesn't erase the application's responsibility for idempotency.

Delayed messages handle a large part of ordinary scheduling, including short retry cooling periods, but their maximum delay is 7 days. For a cleanup due later, store the due date in application state and let cron enqueue it when it enters the working horizon. Don't daisy-chain delays. The message size limit is 256KB, so a job should carry an object key, tenant ID, and stable operation ID rather than a catalog file or full webhook body.

That boundary is boring on purpose.

Capacity budgets expose the cleanup control plane

Suppose a seller closes a shop while 18,000 listing images are still eligible for cleanup. The control plane divides them into bounded batches and publishes cleanup_batch jobs. A worker deletes one batch, records the business result against marketplace-cleanup-2026-08-15-b042, and only then acknowledges the message. If the acknowledgement is lost, standard at-least-once delivery may expose the message again; the second worker sees the committed operation ID and performs no second business effect. This is the incident-review invariant I care about: repeating delivery must not repeat the effect. FIFO's 5-minute deduplication window can reduce immediate duplicates, but it can't replace a durable application record when a retry arrives later.

Now put the capacity numbers beside the invariant. If producers create 40 batches per second for 10 minutes and workers sustain 28, backlog increases by 7,200 jobs. A queue makes that pressure visible and lets consumers drain it, but it doesn't make the deficit disappear. The SLO should name maximum oldest-job age, not merely worker availability, and concurrency must respect storage, email, and webhook rate limits. Reserve some worker capacity for retries; otherwise a fresh burst can starve recovery traffic precisely when dependencies are least cooperative.

Cron has different failure semantics. Pausing it does not backfill missed triggers, trigger timing can jitter by seconds, and its stored run output keeps only the first 4KB. Therefore the database remains authoritative for which cleanup windows are due. A cron tick is a hint to inspect durable state and enqueue work, never proof that every expired listing was processed.

No commit, no ack.

Compare two viable architectures by invariant

Both shapes below can be defensible. The choice turns on retry ownership and operational scope, not fashion.

Shape	Required invariant	Best fit	Operational catch
Queue-led execution, cron-assisted scheduling	Every message has a stable operation ID; the worker commits once before acknowledging	Bursty files, email, webhooks, and cleanup with independent retry policies	Requires backlog-age monitoring and idempotent consumers
Database-led scheduler	Claiming a due row and changing its state are atomic; expired claims are recoverable	Low-volume cleanup already centered on one transactional database	Scans, retry state, and business queries share one capacity pool

The database-led shape is the smaller system when cleanup is infrequent, the table is already the source of truth, and execution can tolerate the polling interval. A Node.js process claims due rows, performs bounded work, and returns expired claims to the pool. I'd keep it for a modest internal housekeeping task rather than buy infrastructure automatically.

The queue-led shape wins once file arrivals are bursty or email and webhook sync have distinct downstream limits. Producers publish independently, workers scale by job type, and delayed delivery covers schedules up to the 7-day ceiling. For later dates, cron queries authoritative due state and creates ordinary jobs. These are two cooperating control loops, not two competing ways to run the same callback.

The buy-versus-build decision still needs real alternatives:

Option	Control-plane fit	Prefer it when	Avoid it when
Infrai	Managed queue and cron over plain HTTP	A small team values one contract across multiple backend modules	Kafka-style replay, private push delivery, or workflow joins are required
BullMQ	Node.js-oriented job processing	Tight Node.js integration and ownership of the backing stack are acceptable	The on-call team doesn't want a runtime-specific queue stack
RabbitMQ	Broker with explicit consumer acknowledgements	Broker routing and acknowledgement controls are central	Broker operations exceed the team's capacity budget
GitHub Actions	Repository workflow schedules	Cleanup is repository maintenance rather than application traffic	It would become the SaaS job data plane
Temporal	Durable workflow execution	Long waits, compensations, and multi-step recovery define the work	Jobs are single-step file, email, webhook, or cleanup effects

I'm not sure where the database-led shape stops being cheaper to own for a particular marketplace. Queue arrival distribution, p95 service time, retry rate, and the team's on-call history would settle that. A vendor demo won't.

Implement the Go publication call

Publication is the first write boundary. This complete Go program uses the verified queue route, reads the current JSON body from an environment variable rather than inventing schema fields, supplies a stable idempotency key, checks every status, and backs off on HTTP 429 while honoring an integer Retry-After value. The discovery documentation should supply INFRAI_QUEUE_PUBLISH_JSON for the queue type being deployed.

package main

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

func main() {
    apiKey := os.Getenv("INFRAI_API_KEY")
    jobID := os.Getenv("MARKETPLACE_CLEANUP_JOB_ID")
    payload := os.Getenv("INFRAI_QUEUE_PUBLISH_JSON")
    if apiKey == "" || jobID == "" || payload == "" {
        log.Fatal("set INFRAI_API_KEY, MARKETPLACE_CLEANUP_JOB_ID, and INFRAI_QUEUE_PUBLISH_JSON")
    }

    client := &http.Client{Timeout: 15 * time.Second}
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(
            http.MethodPost,
            "https://api.infrai.cc/v1/queue/publish",
            bytes.NewBufferString(payload),
        )
        if err != nil {
            log.Fatal(err)
        }
        req.Header.Set("Authorization", "Bearer "+apiKey)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", jobID)

        resp, err := client.Do(req)
        if err != nil {
            log.Fatal(err)
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            log.Fatal(readErr)
        }

        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            fmt.Println(string(body))
            return
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            log.Fatalf("publish rejected: status=%d body=%s", resp.StatusCode, body)
        }

        wait := time.Duration(1<<attempt) * time.Second
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && seconds >= 0 {
            wait = time.Duration(seconds) * time.Second
        }
        time.Sleep(wait)
    }

    log.Fatal("publish remained rate limited after 5 attempts")
}

The key protects publication retries for the documented 24-hour default deduplication window. The worker still needs its own durable DoOnce(jobID) guard because standard queue consumption is at least once and business retries can outlive transport deduplication. Acknowledge only after that guard and the intended effect commit together; a failed effect should remain eligible for retry.

Push delivery changes reachability, not the invariant. Its subscriber must be a public HTTPS endpoint, so internal-only workers should poll. Your mileage may vary on which topology is easier: public ingress adds an authentication and exposure review, while polling adds worker lifecycle and empty-consume behavior to the runbook.

Rollout gates and specialist escape hatches

The catch is that a queue is not an event archive. Messages are retained for at most 30 days and are deleted on acknowledgement, with no Kafka-style replay or multiple consumer groups. There is no native topic fan-out, debounce, throttle, DAG orchestration, or fan-out/join primitive. Simulating independent consumers requires separate queues; simulating a durable workflow in payload fields creates a state machine nobody can inspect reliably.

Stick with RabbitMQ when its routing model and broker controls are requirements the team already knows how to operate. Pick Temporal when cleanup spans durable waits, compensations, and dependent steps. Use a database-led scheduler when volume is low and transactional row claiming is the simplest honest design. Infrai is not suitable when private-only push endpoints, replayable event history, or workflow orchestration are hard requirements.

For the narrower marketplace problem, the decision rule is stable: queue the work, make effects idempotent, and let cron create jobs only when wall-clock eligibility exceeds what a delayed message can express. Capacity-plan against backlog age. Then test duplicate delivery before launch, because the happy path says almost nothing about whether the system can recover.

If this boundary fits your system, start with the queue and cron guide at https://docs.infrai.cc/en/guides/queue/answers/background-job-queue-vs-cron-for-file-processing-email/ and verify the live schema before rollout.