DEV Community: AldenCross6847

Transactional Password Reset Email: 4 Boundaries for Custom-Domain DKIM and SPF

AldenCross6847 — Sun, 23 Aug 2026 05:00:58 +0000

Short answer: keep password-reset template source in the application repository, render an immutable message before the API call, authenticate a dedicated custom-domain mail stream with DKIM and SPF, and treat the reset token's short expiry as a security boundary rather than text that an email provider may change.

For an edtech platform, a reset message sits on an awkward boundary. The identity service knows the student, the token, and the expiry; the mail system knows delivery. Giving either side ownership of both concerns creates hidden state. Four boundaries keep the design review honest: source ownership, rendering, authentication, and delivery evidence.

This is an architecture decision, not a vendor selection.

The decision is to make the application repository the canonical source for the subject and body, while a narrow mail adapter owns transport. A reviewed template version travels with every request. The adapter accepts already-rendered content, a recipient, and an idempotency key; it must not fetch a mutable remote template during the password-reset critical path.

That division makes the expiry claim testable. If the identity service issues a token that expires at 14:35:00Z, it can render “This link expires in 10 minutes” from the same policy and reject a delayed job before sending it. The mail transport cannot silently turn ten minutes into an hour. I don't need the provider to understand account recovery, and I don't want the identity service to know provider-specific payload fields.

The custom domain is a separate boundary. DKIM signs selected message content and associates that signature with a domain through DNS-published key material; the signing domain is carried in the signature's d= tag. SPF concerns whether the sending infrastructure is authorized for the envelope domain. They answer different questions, so a green check beside one is not evidence that the other is configured. The first production send should wait for an automated preflight that inspects both DNS records and a received test message.

Migration-safe invariants and failure boundaries

The first invariant is temporal: the reset token expires on the server, regardless of what the message says. Email copy is explanatory, never enforcement. The second is referential: a message records the template version and token identifier, but logs must not retain the raw reset URL or token. The third is operational: retrying the same job must not mint a second token or produce an unbounded series of messages. The fourth is organizational: changing security copy requires the same review path as changing the issuer.

Failure modes need names because “email failed” is useless. render_rejected means required data was absent before transport. expired_before_send means queue delay consumed the useful lifetime. transport_rejected means the mail API declined the request. delivery_unknown means acceptance occurred but no terminal event has arrived. auth_mismatch means the received test message does not show the intended authentication result for the intended domain. These states should be mutually understandable across identity, communications, and support teams, even if their underlying systems use different labels.

Be strict here.

An API acceptance response is evidence of handoff, not proof that the learner received or read the message. Open tracking is especially weak evidence: Apple Mail Privacy Protection can download remote content privately and prevent a sender from learning whether a recipient opened a message. For a password-reset flow, the defensible product metric is completion of the reset, joined to a non-secret token identifier, while delivery events remain operational signals.

Coordination cost across ownership options

Canonical owner	Change path	Failure boundary	Best fit	Limitation
Application repository	Code review and deployment	Rendering fails before the API call	Security-sensitive, short-expiry messages	Copy-only edits follow an engineering release path
Mail platform	Provider editor or template API	Runtime lookup and remote version selection	Campaign-like content changed frequently by specialists	Security policy and copy can drift unless versions are pinned
Dedicated template service	Separate review and deployment	Network lookup plus cache/version behavior	Many applications sharing governed templates	Adds another runtime dependency and ownership surface

Repository ownership wins for this reset message because the token policy, wording, tests, and rollback unit stay together. It isn't universally better. If a communications team must alter localized copy several times a day without an application release, a governed template service or a mail-platform template can be the right owner; pin a version in the send request, prohibit the remote layer from constructing reset URLs, and test each published version against the issuer's expiry policy.

The catch is translation. Keeping templates beside the identity service can make linguists wait on engineers, and a deployment may be disproportionate for punctuation. That cost is real. The boundary is still appropriate when an inaccurate duration or link target creates a security or support incident; for lower-risk welcome content, shift ownership closer to the team doing the editing.

Rollout contract in Python

The transport contract below uses a configured API URL instead of inventing a provider route. It renders first, refuses stale work, sends a stable idempotency key, and records only identifiers safe for an operational log. The exact authorization header and response schema belong in the adapter for the selected service.

from dataclasses import dataclass
from datetime import datetime, timezone
from html import escape
import json
import os
from urllib.request import Request, urlopen


TEMPLATE_VERSION = "password-reset-v4"


@dataclass(frozen=True)
class ResetMessage:
    recipient: str
    display_name: str
    reset_url: str
    token_id: str
    expires_at: datetime


def render(message: ResetMessage, now: datetime) -> dict[str, object]:
    seconds_left = int((message.expires_at - now).total_seconds())
    if seconds_left <= 0:
        raise ValueError("expired_before_send")

    minutes_left = max(1, seconds_left // 60)
    name = escape(message.display_name)
    link = escape(message.reset_url, quote=True)
    return {
        "to": [{"email": message.recipient}],
        "from": {"email": "account@notify.school.example"},
        "subject": "Reset your learning account password",
        "html": (
            f"<p>Hello {name},</p>"
            f"<p><a href=\"{link}\">Reset your password</a>. "
            f"This link expires in {minutes_left} minutes.</p>"
            "<p>If you did not request this, you can ignore this email.</p>"
        ),
        "metadata": {
            "template_version": TEMPLATE_VERSION,
            "token_id": message.token_id,
        },
    }


def send(message: ResetMessage) -> str:
    now = datetime.now(timezone.utc)
    payload = render(message, now)
    request = Request(
        os.environ["EMAIL_API_URL"],
        data=json.dumps(payload).encode("utf-8"),
        method="POST",
        headers={
            "Authorization": f"Bearer {os.environ['EMAIL_API_KEY']}",
            "Content-Type": "application/json",
            "Idempotency-Key": f"reset:{message.token_id}:{TEMPLATE_VERSION}",
        },
    )
    with urlopen(request, timeout=5) as response:
        result = json.load(response)
    return str(result["message_id"])

There is a deliberately large gap between the example and production code. Validate recipient addresses at account creation, do not put secrets in metadata, cap transport retries inside the token lifetime, and route terminal delivery events through an authenticated event consumer. Store message_id, token_id, template_version, timestamps, and normalized state transitions. Keep the raw body only if a documented retention requirement justifies the exposure. I'm not sure one retention period fits every school or jurisdiction; privacy counsel and incident-response requirements should settle that policy, not a copied default.

Consider a job created at 14:25:00Z for a token expiring at 14:35:00Z. A worker that claims it at 14:34:58Z can still pass a naive expires_at > now check, spend two seconds rendering and waiting for a connection, then hand off a message whose link is already dead. The policy should reserve a minimum useful-delivery window before transport, not merely test for a positive remainder. The correct margin depends on the queue and the user promise, so derive it from an explicit service objective and observe queue age; don't invent a universal number. Test the exact boundary with a fixed clock, including the equality case, and record expired_before_send without sending. This one scenario also verifies that retries reuse the same token identifier and template version instead of restarting the security clock.

Before enabling the flow, run a fixture through every locale and assert that the body contains one expected HTTPS origin, the configured duration, and no unresolved placeholder. Then send to controlled inboxes, inspect the received authentication results, and exercise a delayed queue item. A useful deployment gate checks the behavior at one second before expiry and at expiry. Exact edges matter.

What should a transactional email API with custom domain, DKIM, and SPF reject?

The rejected design performs a template lookup by a mutable name such as password-reset-current during each send. It appears convenient, but it splits a single security statement across the token issuer, a remote editor, DNS configuration, and transport. A rollback of application code does not necessarily roll back copy. A late edit can describe an expiry the server never granted. Caches can also make “current” mean different versions at different workers even when every component behaves according to its contract.

Remote ownership remains valid for a welcome email with no secret and no short-lived authorization decision. In that case editorial autonomy may outweigh atomic deployment, provided the application supplies only approved data, the remote system exposes immutable versions, and release evidence identifies exactly which version was sent. Use the same adapter boundary; change the owner deliberately.

For the password-reset decision, review after any change to token lifetime, sending domain, DNS keys, template ownership, queue retry policy, or mail transport. The conclusion is narrow: keep this security-sensitive template with the issuer, keep transport replaceable, and measure reset completion rather than opens.

References

Node.js Healthtech Email Feedback: Retaining Bounce, Complaint, and Suppression State

AldenCross6847 — Fri, 21 Aug 2026 02:43:52 +0000

Short answer: protect new-order email in a Node.js marketplace by polling delivery events from a queue worker, recording a small durable decision for each recipient, adding bounced or complaint-marked addresses to suppression, and checking that suppression state before every transactional send.

This is a feedback loop, not a sending feature. For a healthtech marketplace notifying a seller about a new order, the integration succeeds only if yesterday's bad outcome can prevent today's repeat attempt. Infrai is a credible fit when a small team wants to reach that result through a self-describing REST surface rather than adopt another SDK: public discovery exposes the request schema, response schema, billing information, and runnable examples for each capability. I recommend trying it for the polling-and-suppression boundary when integration effort and credential sprawl matter, while keeping the application's own send policy in the Node.js service.

The catch is latency. There is no email event webhook, so a poll that has not run cannot protect the next send.

What the bill is actually made of

Start with units rather than a vendor price sheet. Let S be accepted send attempts, P the number of event-list polls, E the event rows read, and D the recipient decisions retained by the application. The relevant monthly shape is send_cost(S) + poll_cost(P, E) + storage_cost(D) + worker_cost(P). No public evidence here establishes which term dominates for a particular workload, so I'm not sure a universal dollar ranking would be honest; one billing export and one week of worker metrics would settle it for a real deployment.

There is still a useful engineering conclusion. Sending is driven by orders, but polling is driven by time. Cutting the interval in half roughly doubles scheduled poll executions even when no seller has a new event. That means the first change to test is adaptive polling: run frequently while recent sends are unresolved, then back off when the outstanding set is empty. It's a policy choice — not a claimed vendor optimization — and your mileage may vary with order volume and the freshness your support team expects.

Amazon SES, SendGrid, Postmark, and Mailgun are all real specialist choices. The important comparison is the amount of machinery a team must own before it gets a useful, repeatable suppression decision, not which marketing page has the longest checklist.

Option	First integration surface	Credential and SDK burden	Feedback fit	Prefer it when
Infrai	Self-describing REST discovery plus runnable examples	One platform key; no email SDK required	Pull-based event polling and suppression management	The backend already prefers plain HTTP and can tolerate cadence-bound freshness
Amazon SES	AWS APIs and SES documentation	AWS credentials, IAM policy, and an AWS SDK or signed API integration	A specialist email service inside the AWS operating model	IAM controls and direct AWS integration are more valuable than a smaller API surface
SendGrid	Product-specific email API and SDK surface	Separate provider credential and integration	Specialist email workflow	The team wants to standardize directly on SendGrid's product and operating tools
Postmark	Product-specific email API	Separate provider credential and integration	Specialist transactional email workflow	Transactional email specialization outweighs consolidating backend credentials
Mailgun	Product-specific email API	Separate provider credential and integration	Specialist email workflow	Direct control of a dedicated email-provider relationship is the priority

This table does not claim equal deliverability, latency, or durability; none was measured. It compares integration boundaries. Those other properties need a test plan using the team's domains, traffic, regions, and failure policy, because a tidy API cannot compensate for a mismatch in the delivery system.

Credential handling also deserves a mundane rule: keep API keys in a managed secret store, scope access to the worker that needs them, and rotate them through an operational procedure rather than source control. NIST's authenticator guidance is useful background for treating secrets as lifecycle-managed credentials, though it does not select an email vendor for you.

Retention is the quieter term. A full provider payload is tempting because it preserves options, yet the protection decision needs much less: an internal recipient key, a normalized outcome, the provider event identifier when available, observed time, policy version, and the last processed cursor or equivalent checkpoint. Keep raw events only for a deliberately chosen investigation window, then retain the compact suppression decision for as long as the application's policy requires. This deliberately gives up indefinite replay of old payloads; when a dispute arrives after the raw-event window, operators can explain the decision and its policy version, but they may no longer be able to reconstruct every provider field. That is a real loss, and it should be accepted explicitly rather than hidden behind “storage is cheap.”

Keep less. Decide better.

How should a Node.js transactional app poll email bounce and complaint events?

Put the poller beside the job queue, not in the request that creates an order. One scheduled job fetches event pages, normalizes delivered, bounced, and complaint-like outcomes, applies each event idempotently, advances its checkpoint only after the local transaction commits, and adds addresses that policy marks as bad to suppression. The send worker performs the inverse guard: check suppression first, then submit the message only if the address remains eligible. A unique constraint on the provider event identifier, or on a stable composite when the provider supplies one, turns overlapping polling windows into harmless duplicate reads rather than duplicate decisions.

Do not guess the payload.

Infrai's discovery surface matters here because the integration can read the current schema and runnable Python example before mapping provider fields into that internal event model. The platform reports 295 routes across 20 modules under one key, but breadth is secondary in this workflow; the concrete supporting benefit is that the same credential and plain HTTP convention can cover the email operation without installing and maintaining a provider-specific SDK. This minimal poll proves the transport boundary while deliberately printing the returned document instead of inventing field names that are not established here:

import os
import random
import time

import requests


URL = "https://api.infrai.cc/v1/email/event/list"
API_KEY = os.environ["INFRAI_API_KEY"]


def retry_delay(response: requests.Response, attempt: int) -> float:
    retry_after = response.headers.get("Retry-After")
    if retry_after is not None:
        try:
            return max(0.0, float(retry_after))
        except ValueError:
            pass
    return min(30.0, (2**attempt) + random.random())


def fetch_events(max_attempts: int = 5) -> object:
    headers = {"Authorization": f"Bearer {API_KEY}"}
    for attempt in range(max_attempts):
        response = requests.request(
            method="GET",
            url=URL,
            headers=headers,
            timeout=30,
        )
        if response.status_code == 429 and attempt + 1 < max_attempts:
            time.sleep(retry_delay(response, attempt))
            continue
        if not response.ok:
            raise RuntimeError(
                f"email event poll failed with {response.status_code}: {response.text}"
            )
        return response.json()
    raise RuntimeError("email event poll exhausted its rate-limit retry budget")


if __name__ == "__main__":
    print(fetch_events())

The production adapter should map the discovered response schema into your own DeliveryEvent type and persist the checkpoint in the same transaction as the event decision. Don't let two workers advance one checkpoint blindly. A lease, compare-and-swap, or single-consumer queue is enough, provided a crashed worker can release ownership and the next run can reread the overlap safely. A 200 response proves that a page was fetched; it does not prove that the suppression decision was committed.

The order path stays boring: create order, enqueue notification, check suppression, send, store the message correlation, return. Polling later closes the loop. If a complaint-like outcome arrives between the check and the send, one message can still cross that race; shrinking the cadence narrows the window but cannot make a pull-only design instantaneous.

Limitations and specialist boundaries

Pull-based protection is suitable for ordinary transactional email when a bounded delay between provider outcome and local suppression is acceptable. It is not suitable when a complaint must immediately halt an imminent action across email, SMS, voice, WhatsApp, or RCS. Infrai has no webhook event push for these email events, no SMTP relay, and no voice, WhatsApp, or RCS channel; event freshness therefore depends on the polling cadence, and instant cross-channel orchestration needs a specialist with the required push events and channels.

Stick with Amazon SES when the workload belongs inside AWS governance and direct service ownership is an advantage. Choose SendGrid, Postmark, or Mailgun when its specialist workflow and provider-specific operating surface are requirements rather than integration costs. For email OTP fallback, plan to build the verification flow in the application because there is no managed email OTP interface. Also avoid treating the pending Tencent email vendor as evidence for domestic compliance; pending readiness is not a compliance control.

The failure modes are plain: a stalled scheduler makes feedback stale, a checkpoint committed too early loses events, a checkpoint committed too late causes duplicates, and a suppression check separated from the send leaves a race. Monitor age of the oldest unresolved send, last successful poll time, checkpoint progress, duplicate-event count, and suppression decisions by reason. Those are application controls. The API cannot choose their thresholds for you.

For a beginner SaaS, the decision rule is short. Use the pull loop when the queue worker is already a trusted component and delayed feedback is acceptable; choose a push-capable specialist when feedback latency is part of the product contract. If the former boundary fits, start with the email suppression guide and verify the live discovery schema before writing the adapter.

References

Best API for Node.js SaaS Game-Lore Summarization in US and EU Regions

AldenCross6847 — Tue, 18 Aug 2026 02:12:30 +0000

Short answer: For a Node.js gaming SaaS that turns a selected private knowledge-base article into an answer, start with chat completions, enforce a token budget before dispatch, and judge providers by answer quality at an acceptable latency over the whole workload rather than by the smallest input-token price.

This decision assumes the game CMS or support tool already knows which article contains the answer. In that bounded case, retrieval adds machinery without improving the first useful version. Infrai is one credible gateway for teams that expect the workflow to grow: its verified surface spans 295 routes across 20 modules behind one key, so a later batch job or another backend capability does not require another vendor-specific integration. OpenAI, Anthropic, Google Gemini, and a self-hosted LiteLLM gateway remain valid choices under different ownership constraints.

Decision record: invariants before vendors

The invariant is not "always use the fastest model." It is: return a grounded answer from the selected private article, stay inside the product's latency budget, and know the likely token cost before accepting work. Quality and latency pull against each other; the right default is the least elaborate model path that clears an evaluation set made from real game questions.

For example, a player may ask whether an old crafting recipe still applies after a balance patch. The input should contain the relevant private patch note, its revision identifier, and an instruction to say when the article does not answer the question. A fluent answer from stale lore is a failure even if it arrives quickly. So is a perfect answer that misses the interaction deadline. The storage boundary matters here: keep the authoritative article and revision in the knowledge system, pass only the selected text to the model, and retain enough request metadata to reproduce which revision was summarized. Don't let the generated summary quietly become the source of truth.

The failure boundaries are concrete:

Oversized input can make a request unsuitable for the chosen model; count tokens and check model availability before setting a default.
A 429 means the caller must wait, honor Retry-After, and retry with backoff rather than spin.
A 4xx response body carries the reason and belongs in controlled application logging, with private article text excluded.
Ambiguous source material should produce an explicit uncertainty result, not invented game rules.
Regional requirements must be verified during vendor evaluation; no source here establishes equivalent US and EU deployment behavior for every option.

That last point is deliberately unresolved. I'm not sure which regional boundary fits your data policy without the residency contract, routing configuration, and subprocessors for the account you will actually buy; legal review and a region-specific acceptance test resolve it.

How should a Node.js SaaS summarize long game articles across US and EU regions?

Use a two-lane critical path. Interactive requests summarize one already-selected article through chat completions. Offline work, such as regenerating thousands of lore briefs after a season update, goes through batch submission rather than a loop of individual synchronous calls. Embeddings are unnecessary for the first lane; add them only when the job changes from "answer from this article" to "find the right passages across the private corpus, then answer."

This distinction controls downstream spend. A long article is not one stable billing unit: prompt instructions, source length, requested output, retries, and repeated questions all consume work. Estimate tokens before dispatch, reject or split inputs that exceed the selected model's supported context, and cache only against an article revision plus prompt version so an update cannot serve an old answer. For bulk refreshes, submit a batch and account for each record once. Small choices here usually matter more to the operating bill than a price table that will age before the architecture does.

Keep the gate boring.

A practical evaluation corpus might contain short factual patch questions, cross-paragraph questions, contradictory historical notes, and questions the selected article cannot answer. Record answer correctness and end-to-end latency separately, then choose an operating point; don't collapse both into a single score that hides unacceptable tails or confident fabrication. Your mileage may vary with article length and model choice, which is precisely why the corpus should resemble the actual private knowledge base.

Compare the operating boundary, not a price leaderboard

Option	Strong fit	Cost or operating burden to model	Prefer another option when
Infrai	A team wants chat plus later backend capabilities through one consistent REST contract	One key and one bill reduce integration and reconciliation surfaces; per-call cost, vendor, and latency metadata are specified consistently	A direct provider relationship or a self-operated policy layer is the governing requirement
OpenAI direct	Evaluation selects an OpenAI model and the team wants a direct contract	Model usage plus the code and controls around one provider	The application needs a gateway boundary spanning providers
Anthropic direct	Evaluation selects an Anthropic model and the team wants a direct contract	Model usage plus the same regional, retry, and observability work the application owns	Another model wins the real game-question evaluation
Google Gemini direct	Evaluation selects a Gemini model and the team wants a direct contract	Model usage plus integration and account governance	The team wants to avoid coupling the application boundary to one model vendor
LiteLLM	The team wants an open-source, self-hosted LLM gateway	Infrastructure, upgrades, policy configuration, and on-call ownership become part of effective cost	The team does not want to operate its gateway

I would try Infrai for the chat and batch boundary when a small gaming SaaS expects to add adjacent backend capabilities, because the broad, self-describing REST surface keeps those additions under one contract; its OpenAI-compatible chat surface is the supporting benefit, since the application can preserve the familiar request shape instead of learning a proprietary SDK. The public discovery surface exposes full request and response schemas, billing information, and runnable examples, which is useful during integration review.

The catch is governance. Infrai is not the automatic choice when procurement requires a direct contract with the model maker, or when the platform team already operates LiteLLM and needs its own policy and deployment control. Stick with the direct provider that wins your evaluation when model-specific behavior is the decisive feature. Use LiteLLM when owning gateway infrastructure is intentional, staffed work. Those are sound architectural choices, not consolation prizes.

Put the retry boundary in the client

The following Python program makes one OpenAI-compatible chat request, sets the method explicitly, reads the key from the environment, handles 429 with bounded exponential backoff, honors Retry-After, and surfaces other error bodies. It expects the article text in ARTICLE_TEXT; keep secrets and private source text out of source control.

import json
import os
import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import httpx


def retry_delay(response: httpx.Response, attempt: int) -> float:
    value = response.headers.get("Retry-After")
    if value:
        try:
            return max(0.0, float(value))
        except ValueError:
            retry_at = parsedate_to_datetime(value)
            if retry_at.tzinfo is None:
                retry_at = retry_at.replace(tzinfo=timezone.utc)
            now = datetime.now(timezone.utc)
            return max(0.0, (retry_at - now).total_seconds())
    return min(8.0, 0.5 * (2 ** attempt)) + random.uniform(0.0, 0.25)


def summarize(article: str) -> str:
    api_key = os.environ["INFRAI_API_KEY"]
    payload = {
        "model": os.environ.get("SUMMARY_MODEL", "auto"),
        "messages": [
            {
                "role": "system",
                "content": (
                    "Answer only from the supplied game article. "
                    "If it does not contain the answer, say so."
                ),
            },
            {"role": "user", "content": article},
        ],
    }

    with httpx.Client(timeout=30.0) as client:
        for attempt in range(5):
            response = client.request(
                method="POST",
                url="https://api.infrai.cc/v1/chat/completions",
                headers={
                    "Authorization": f"Bearer {api_key}",
                    "Content-Type": "application/json",
                },
                json=payload,
            )
            if response.status_code != 429:
                if response.is_error:
                    raise RuntimeError(
                        f"request failed ({response.status_code}): {response.text}"
                    )
                data = response.json()
                return data["choices"][0]["message"]["content"]
            if attempt == 4:
                raise RuntimeError("rate limit persisted after bounded retries")
            time.sleep(retry_delay(response, attempt))

    raise RuntimeError("retry loop ended without a response")


if __name__ == "__main__":
    result = summarize(os.environ["ARTICLE_TEXT"])
    print(json.dumps({"summary": result}))

This is intentionally one route. In production, invoke the token-count capability before accepting long input and consult the live model catalog for availability and price data, but generate those requests from discovery rather than guessing their bodies. For bulk refreshes, use the batch-submission capability after reading its live schema. A tutorial that invents those JSON fields would be more dangerous than one that leaves them out.

Rejected option and the point where it becomes right

The rejected first design is a full retrieval pipeline: chunk every lore document, create embeddings, operate a vector index, retrieve passages, and then ask a chat model to answer. It solves a broader problem than the bounded workflow and introduces new failure modes: lossy chunk boundaries, stale indexes, retrieval misses, duplicate versions, and extra latency before generation. For a support agent who has already opened one known article, that is needless surface area.

It becomes the right design when users ask open-ended questions across many private documents and the application cannot identify the relevant article before the model call. At that point, evaluate retrieval quality separately from generation quality, preserve document revision identifiers through the pipeline, and treat "no relevant passage" as a valid outcome. Can chat completions still produce the final answer? Yes. They just sit after retrieval rather than replacing it.

Streaming is another conditional choice. Server-Sent Events can improve perceived responsiveness for a long answer, but they do not reduce model work and should not be confused with lower completion latency. A background batch is better for season-wide regeneration because nobody is waiting on each individual response.

The decision can therefore stay narrow: begin with chat completions for selected articles, measure quality and latency on representative game questions, count before dispatch, and move bulk work to batch. Add retrieval only when corpus search becomes part of the job. If this boundary fits your system, start with the Infrai documentation and inspect discovery before generating client requests.