DEV Community: LinusHolm3764

Feature Flags API: How to Retry 429 Rate Limits in Node.js

LinusHolm3764 — Wed, 14 Oct 2026 19:27:38 +0000

TL;DR: For a property-management AI agent, use a basic flag as a kill switch, cache each read, and retry HTTP 429 responses with Retry-After or bounded exponential backoff. Pick a dedicated flag platform when reconstructing who changed a rollout, or measuring evaluations, matters more than keeping the client contract small. A poll-only API can control the loop. It cannot explain the whole incident.

Choice	Client update model	Incident reconstruction	Best fit
Basic REST flags	Polling	Limited: no change audit log or evaluation statistics	A small contract with few dependencies
LaunchDarkly	SDK streaming or polling, depending on SDK and configuration	Dedicated platform with flag change history and evaluation data	Teams that need mature rollout forensics
Unleash	SDKs fetch and cache feature configuration	Dedicated feature-management workflow	Teams that prefer an open feature-management platform
ConfigCat	SDK polling modes and local caching	Dedicated feature-management workflow	Teams that want a focused hosted flag service
Sentry	Not a flag delivery service	Error events and issue investigation	Teams reconstructing failures and crashes
Datadog or Grafana	Not a flag delivery service	Broader telemetry investigation	Teams correlating agent latency, cost, and service health

My decision rule is blunt: start with the smallest contract only if the flag answers a small question. For example, “may the lease-renewal agent call the model?” Infrai fits that case because one key reaches a broad set of capabilities through one REST API, and the contract can stay put while the provider behind a capability changes. Its limitations are decisive too: if the post-incident question is “who moved which tenants into the rollout, and when?”, it is not suitable because its flags lack a change audit log and evaluation statistics. Choose a dedicated flag system before launch.

How should a Node.js feature flags API client retry 429 rate limits?

Polling looks harmless until every Node.js process wakes on the same interval. A 429 then triggers another immediate request, which triggers another 429. The flag service is now the loudest part of an incident that began somewhere else.

Do less.

Cache the last successful value. Add jitter so replicas do not march together. Bound the number of attempts, honor the server's Retry-After instruction, and keep serving the cached value during the backoff window. Those choices trade freshness for stability. For a kill switch, set the cache lifetime from the maximum delay the operations team can tolerate, not from an arbitrary “real-time” aspiration.

The property-management agent also needs its own event record around each loop: flag key, cached-versus-fresh state, model request identifier, latency, cost, property or tenant correlation identifier, and final outcome. The flag system does not magically join those facts. In particular, basic flags have no change audit log or evaluation statistics, so retaining application-side context is what lets an operator distinguish “the model slowed down” from “an old cached toggle allowed one more loop.”

Implement the polling boundary

This client deliberately returns unknown. The verified contract here establishes the route, not a response field that application code may safely assume. Decode the value at the business boundary after checking the live discovery schema. That is less cute than json.enabled. It is also harder to break.

type CacheEntry = {
  value: unknown;
  expiresAt: number;
};

const cache = new Map<string, CacheEntry>();

function retryAfterMs(header: string | null): number | undefined {
  if (!header) return undefined;
  const seconds = Number(header);
  if (Number.isFinite(seconds) && seconds >= 0) return seconds * 1_000;
  const dateMs = Date.parse(header);
  return Number.isNaN(dateMs) ? undefined : Math.max(0, dateMs - Date.now());
}

function sleep(ms: number): Promise<void> {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

export async function getFlagValue(
  endpoint: URL,
  key: string,
  ttlMs = 15_000,
  maxAttempts = 4,
): Promise<unknown> {
  const saved = cache.get(key);
  if (saved && saved.expiresAt > Date.now()) return saved.value;

  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const url = new URL(encodeURIComponent(key), endpoint);
    const response = await fetch(url, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429) {
      if (attempt === maxAttempts - 1) break;
      const serverDelay = retryAfterMs(response.headers.get("retry-after"));
      const exponential = Math.min(1_000 * 2 ** attempt, 30_000);
      const jitter = Math.floor(Math.random() * 250);
      await sleep((serverDelay ?? exponential) + jitter);
      continue;
    }

    if (!response.ok) {
      const body = await response.text();
      throw new Error(`Flag read failed (${response.status}): ${body}`);
    }

    const value: unknown = await response.json();
    cache.set(key, { value, expiresAt: Date.now() + ttlMs });
    return value;
  }

  if (saved) return saved.value;
  throw new Error("Flag read was rate-limited and no cached value exists");
}

Pass an HTTPS endpoint whose path ends immediately before the encoded flag key. The first call fills a process-local cache; later calls within 15 seconds avoid the network. Four attempts cap the damage. The maximum locally calculated delay is 30 seconds, although a valid Retry-After takes precedence. These are example operating values, not service limits. Benchmark them against the number of processes, acceptable kill-switch delay, and request volume in your deployment.

For multiple replicas, process-local caching still prevents repeated reads inside each process, but it does not coordinate them. The jitter matters. A shared cache can reduce calls further, at the cost of another dependency and another failure boundary. I would earn that complexity with measurements first.

The two criteria that actually decide this

First: can you reconstruct the control-plane change? Application logs can show that a process observed a value. They cannot manufacture a missing flag-change audit trail. With a basic polling capability, record what the application observed and accept that rollout authorship and historical evaluation counts are outside the system. LaunchDarkly is the stronger candidate when those records drive incident review. Unleash and ConfigCat deserve the same proof-of-concept test against your exact retention and export requirements; do not infer forensic depth from the presence of a dashboard. Sentry can add error context, while Datadog and Grafana can help investigate telemetry, but none of those three replaces the flag system's own change record.

Second: what is the stale-value budget? Server push reduces the delay between a change and a client observing it. Polling makes that delay explicit and controllable, but a cache extends it by design. Write the budget down. A leasing assistant that must stop before its next model call may need a shorter TTL than a flag controlling a background summary format.

There is a second boundary people miss. Repeated poll failures do not produce built-in notification routing here. There are no threshold rules, phone calls, SMS messages, or webhook notifications, so production alerts require your own polling and alert path. Silent “the job never ran” failures also need a heartbeat monitor such as Healthchecks. Those are separate jobs from flag evaluation.

When is the runner-up better?

Use LaunchDarkly when change history and evaluation data are required evidence, or when SDK-driven updates are worth a larger integration surface. Choose Unleash when an open feature-management platform and its SDK model fit your operating preferences. ConfigCat is a reasonable focused hosted alternative when its polling modes and SDK cache behavior match your stale-value budget.

OpenFeature is different. It is a vendor-neutral API specification rather than another flag service. Use it when portability at the application interface matters and a provider exists for the backend you select. It adds an abstraction, so test time-to-first-evaluation and error behavior before standardizing it across every service.

Basic REST polling wins when the toggle is simple, the team already owns incident telemetry, and a small dependency surface matters. The trade-off is sparse rollout forensics. It loses when flags become a control plane that auditors and incident commanders must interrogate. No amount of retry code changes that boundary.

Ship with a reconstruction test

Before production, run one controlled exercise: enable the agent for a test property, make one model call, disable it, and then reconstruct the sequence using only retained records. Verify the observed flag value, cache age, request correlation, model latency, cost, and result. Also verify that a forced 429 respects Retry-After, stops after the configured attempt count, and falls back to a prior cached value.

Then remove one record at a time. If losing the flag system's history makes the timeline ambiguous, the dedicated platform is not optional. If your application events still answer the incident questions cleanly, the smaller polling contract is doing enough.

That is the benchmark that matters. Not the prettiest dashboard.

Sources

7 Rollback Drills for Junior Developers Comparing Small Business App Logging APIs

LinusHolm3764 — Mon, 12 Oct 2026 22:11:01 +0000

TL;DR: Run a seven-day rollback evidence drill before choosing between self-hosted Loki and a hosted logging API. Feed both paths the same structured support events, simulate a bad release, and time how long a junior developer needs to reconstruct one customer's incident. Pick the operating model that preserves evidence during rollback with fewer unowned chores. Setup speed matters. Recovery clarity matters more.

For a small customer-support app, the real question is not which log screen looks friendlier. It is whether the team can prove what happened after application code, log schemas, and deployments have moved on. A quick ingestion setup that loses correlation at the first rollback fails in the only moment that counts.

How should a junior developer compare self-hosted and hosted logging paths?

Start with an incident envelope, not a vendor checklist. Every support action should carry a timestamp, severity, service name, environment, release identifier, request or trace identifier, and a pseudonymous customer or case identifier. Keep the human message readable, but put filterable values in stable fields. Never place message bodies, access tokens, or raw personal data in logs just because ingestion accepts arbitrary text.

The release identifier is the hinge. During a rollback, traffic may hit two application versions while delayed jobs from the newer version are still finishing. Without a release field, the timeline hides that distinction. With it, the responder can separate an application regression from an old worker draining its queue.

That is the test.

I use one blunt decision question: Can a developer reconstruct the customer's sequence without opening the production database? The evidence should connect the incoming request, the support-case mutation, the background job, and the final outcome. Logs are evidence, not the whole monitoring system. The SRE guidance on monitoring distributed systems separates logs from the four golden signals of latency, traffic, errors, and saturation. Keep those signals available so an investigator can find the time window before reading individual events.

The smallest working evidence path

Do not begin with dashboards. Begin with one typed event and one transport boundary. This keeps application code independent from the storage decision and makes the drill repeatable.

type SupportEvent = {
  occurredAt: string;
  severity: "info" | "warn" | "error";
  service: string;
  environment: "staging" | "production";
  release: string;
  requestId: string;
  caseId: string;
  action: "case_opened" | "reply_queued" | "reply_sent" | "reply_failed";
  outcome: "accepted" | "completed" | "failed";
  durationMs?: number;
};

interface LogSink {
  write(event: SupportEvent): Promise<void>;
}

async function record(sink: LogSink, event: SupportEvent): Promise<void> {
  await sink.write(event);
}

That interface is deliberately boring. A self-hosted Loki adapter and a hosted API adapter belong outside the business workflow. The same fixture can exercise both. If the logging destination is unavailable, the application needs an explicit policy: block the support action, buffer within a documented bound, or record a local failure signal. There is no universal answer. Silently dropping the event makes the later drill meaningless.

Use synthetic identifiers in the test set. Create a case, queue a reply, mark the send result, deploy a deliberately incompatible display change in staging, then roll the application back. Query the full case timeline afterward. The candidate passes only if the older and newer application events remain distinguishable and searchable through their shared case identifier.

Time three intervals with a stopwatch: first event visible, full case reconstructed, and logging path restored after its own restart or configuration change. These are measurements from your drill, not universal benchmark numbers. Record them beside the exact configuration and event count. Otherwise a neat comparison table is theater.

Measure it.

Which maintenance work can the team actually own?

Self-hosted Loki puts the runtime boundary on the small business. Someone must own deployment changes, storage capacity, retention enforcement, access control, upgrades, and recovery tests. A hosted logging API moves much of the service operation outside the team, but the application still owns field design, redaction, delivery behavior, access policy, and export or deletion requirements. Outsourcing the service does not outsource evidence quality.

Use an ownership ledger instead of a feature matrix:

Drill obligation	Self-hosted path	Hosted API path	Pass evidence
Ingestion interruption	Restore the service and dependencies	Diagnose client delivery and provider reachability	Known gap or verified buffered delivery
Application rollback	Preserve queries across both releases	Preserve queries across both releases	One ordered case timeline
Schema change	Update writers and queries	Update writers and queries	Old and new fields stay interpretable
Retention check	Operate and verify enforcement	Configure and verify the contracted control	Boundary event behaves as expected
Access review	Run the access layer	Review application and service access	Named owner and dated result

Maintenance cost is the time attached to those owned tasks, plus the risk of tasks with no owner. Measure operator minutes during the drill and the frequency your team commits to for upgrades, access reviews, restore tests, and schema checks. Do not turn guesses into a fake monthly total. A junior developer can run the exercise, but the business still needs to name who responds when the logging path itself breaks.

Ownership comes first.

The limitation of the hosted path is dependence on an external service boundary and its available controls. The limitation of the self-hosted path is that a small team owns more failure and recovery surfaces. This trade-off is real. Neither deployment model proves rollback safety, and neither is a fit when its required work has no accountable owner.

What would I change at scale?

I would split transport from incident semantics first. Multiple services should reuse the event envelope and correlation rules, while each service keeps only the action fields it can define precisely. I would add contract tests that reject missing release, case, and request identifiers before deployment. More configuration is not progress unless it closes a measured failure mode.

At higher event volume, benchmark with a representative distribution of event sizes and field cardinality. Track query latency for the actual support-case lookup, ingestion lag, error rate, and saturation of components the team operates. One giant load-test number hides the path a responder uses.

Keep the rollback drill in the release process, but do not force it into every commit. Run cheap schema and adapter tests continuously; schedule the end-to-end evidence drill often enough that credentials, retention, deployment manifests, and responder knowledge cannot quietly decay. The cadence depends on release frequency and incident risk. There is no magic number.

The decision rule

Choose the path whose failed drill produces work your team can detect, assign, and recover. If both pass, compare recurring operator time, recovery complexity, data-handling obligations, and the amount of application glue required. Give setup time a smaller weight because it happens once; evidence recovery and maintenance repeat.

Be skeptical of a five-minute demo. The useful result is a complete incident timeline after a rollback, with known gaps and a named owner for every moving part. Rollback safety is demonstrated behavior, not a deployment label.

References

Google SRE Book, "Monitoring Distributed Systems": https://sre.google/sre-book/monitoring-distributed-systems/
Logback manual, "Appenders": https://logback.qos.ch/manual/appenders.html

Tenant Rollbacks: Feature Flags, Node.js Caching, and Fallback Defaults

LinusHolm3764 — Sat, 10 Oct 2026 23:08:27 +0000

A production Node.js SaaS cohort test is only useful if its feature flags have fallback defaults when the flag service is unavailable. That operational constraint decides the design: cache the last valid snapshot briefly, poll on a deliberate cadence, and reject stale treatment decisions.

TL;DR: Production feature flags work well for comparing tenant cohorts when remote state stays off the request path. Serve a cached decision, use local control defaults at startup and after excessive staleness, and select the polling interval from the rollback objective rather than habit. For changes touching totals, inventory, or payment, stale treatment must eventually lose.

How should Node.js feature flags balance caching and fallback defaults?

Fetching a boolean is easy. Defining which failure wins is the engineering work.

Consider checkout-layout-v2, enabled for selected tenant cohorts. A network lookup on every checkout provides fresh state but makes the control plane part of the purchase path. An unlimited cache keeps checkout independent, then quietly blocks rollback. Defaulting errors to true protects the experiment at the expense of customers.

Use three states: a fresh remote snapshot, a recently stale snapshot, and the in-code default. Fresh is normal. Recently stale absorbs a short outage or failed poll. Once the snapshot passes a declared age limit, use the local default. For this test, that default is false, which means control.

Polling has no universal magic number. Work backward from the rollback objective. If every process must observe a cohort rollback within two minutes, polling every 30 seconds leaves time for jitter and a failed attempt. With 200 processes, that schedule produces about 400 reads per minute before jitter; a five-second cadence produces about 2,400. Those figures are arithmetic, not measured vendor performance.

The trade-off is plain: faster propagation costs more control-plane traffic. Add jitter, or every replica deployed together will poll together too.

Bursts are avoidable.

The smallest implementation I would ship

The application should own defaults and staleness. A narrow adapter should own provider-specific decoding. This boundary matters because a successful response that fails schema validation is still a failed refresh.

type FlagValue = boolean | string | number | null;
type FlagSnapshot = Readonly<Record<string, FlagValue>>;

type PollingFlagsOptions = {
  defaults: FlagSnapshot;
  pollMs: number;
  maxStaleMs: number;
  fetchSnapshot: () => Promise<FlagSnapshot>;
  now?: () => number;
  random?: () => number;
};

class PollingFlags {
  private snapshot: FlagSnapshot | undefined;
  private fetchedAt = 0;
  private timer: ReturnType<typeof setTimeout> | undefined;
  private stopped = true;
  private inFlight: Promise<void> | undefined;
  private readonly now: () => number;
  private readonly random: () => number;

  constructor(private readonly options: PollingFlagsOptions) {
    if (options.pollMs <= 0 || options.maxStaleMs < options.pollMs) {
      throw new Error("maxStaleMs must be at least pollMs");
    }
    this.now = options.now ?? Date.now;
    this.random = options.random ?? Math.random;
  }

  start(): void {
    if (!this.stopped) return;
    this.stopped = false;
    void this.refresh().finally(() => this.schedule());
  }

  stop(): void {
    this.stopped = true;
    if (this.timer) clearTimeout(this.timer);
  }

  get<T extends FlagValue>(key: string): T {
    const usable =
      this.snapshot !== undefined &&
      this.now() - this.fetchedAt <= this.options.maxStaleMs;
    const source = usable ? this.snapshot : this.options.defaults;
    return source[key] as T;
  }

  private refresh(): Promise<void> {
    if (this.inFlight) return this.inFlight;
    this.inFlight = this.options.fetchSnapshot()
      .then((next) => {
        this.snapshot = Object.freeze({ ...next });
        this.fetchedAt = this.now();
      })
      .catch(() => undefined)
      .finally(() => {
        this.inFlight = undefined;
      });
    return this.inFlight;
  }

  private schedule(): void {
    if (this.stopped) return;
    const jitter = 0.8 + this.random() * 0.4;
    this.timer = setTimeout(() => {
      void this.refresh().finally(() => this.schedule());
    }, Math.round(this.options.pollMs * jitter));
  }
}

function retryDelayMs(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter !== null) {
    const seconds = Number(retryAfter);
    if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);
  }
  return 500 * 2 ** attempt;
}

async function fetchInfraiSnapshot(attempt = 0): Promise<FlagSnapshot> {
  const apiKey = process.env.INFRAI_API_KEY;
  const baseUrl = process.env.INFRAI_BASE_URL;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");
  if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");

  const response = await fetch(`${baseUrl}/v1/flags/get_all`, {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (response.status === 429 && attempt < 4) {
    await new Promise<void>((resolve) =>
      setTimeout(resolve, retryDelayMs(response, attempt)),
    );
    return fetchInfraiSnapshot(attempt + 1);
  }
  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Flag fetch failed (${response.status}): ${body}`);
  }

  const payload: unknown = await response.json();
  if (typeof payload !== "object" || payload === null || Array.isArray(payload)) {
    throw new Error("Flag response must be an object");
  }
  return Object.freeze({ ...(payload as FlagSnapshot) });
}

const flags = new PollingFlags({
  defaults: { "checkout-layout-v2": false },
  pollMs: 30_000,
  maxStaleMs: 90_000,
  fetchSnapshot: fetchInfraiSnapshot,
});

flags.start();

export function checkoutLayout(): "control" | "v2" {
  return flags.get<boolean>("checkout-layout-v2") ? "v2" : "control";
}

The cache remains provider-neutral; fetchInfraiSnapshot is the replaceable adapter. In production, generate its inner validator from the public discovery response schema rather than spreading hand-written casts through checkout code. The outer object check shown here rejects obviously malformed payloads, status failures retain the prior snapshot, and a 429 honors a numeric Retry-After value before falling back to bounded exponential delays.

One subtle mistake deserves attention: updating fetchedAt after an error makes an old snapshot appear fresh forever. The timestamp above changes only after a valid fetch resolves. The implementation also coalesces refreshes, so a slow attempt cannot pile up behind the next timer. Small details. Large consequences.

For an Infrai adapter, the verified bulk read is GET /v1/flags/get_all, authenticated with a bearer key. Its clients refresh flags by polling. The flag surface has no change audit log, evaluation statistics, parent-child dependencies, or deletion recovery, so do not infer those controls from the compact integration.

Comparing the real options

Rollback safety depends on more than flag delivery. Governance, deployment ownership, propagation model, and dependency weight all count. These products make different trades.

Option	Useful fit	Boundary for this experiment
LaunchDarkly	A dedicated feature-management platform with server-side SDKs and streaming or polling	Better when rapid propagation and mature governance justify a dedicated platform and SDK
Unleash	Open-source feature management with server-side SDKs, activation strategies, and self-hosting	Good when deployment and data control matter; self-hosting also creates operational ownership
ConfigCat	A managed flag service whose SDKs offer configurable polling modes and caching	Good for a focused managed setup; it remains another SDK and control plane to operate
Infrai	Plain REST flag access within a broader backend API, using one credential and consolidated billing	Good when a small team values little integration glue; weak when flag audit history, evaluation analytics, dependencies, or deletion recovery are requirements

Infrai has two relevant advantages, and they are different. First, one key spans 295 routes across 20 modules, with one bill instead of separate credentials and invoices for each backend service. In this workflow, that reduces secret rotation and month-end reconciliation around the experiment. Second, its public discovery surface needs no key and exposes request and response schemas, billing metadata, and runnable examples; every documented capability has examples in 10 languages. That makes generated validation at the adapter boundary practical. It does not compensate for the missing flag-governance features.

LaunchDarkly's streaming option can propagate changes without waiting for the next scheduled poll. Unleash offers deployment control, but someone must operate what the team hosts. ConfigCat offers multiple polling approaches through its SDKs. A plain REST integration keeps the dependency graph small while making cache correctness your responsibility.

Choose from the rollback requirement. If changes must propagate in seconds and an audit trail must show who changed what, use a dedicated system that supplies those controls. If a two-minute objective is acceptable and the team already benefits from a consolidated backend surface, a small polling adapter can be the cleaner fit.

Measure the decision, not the current flag

A flag value is not experiment evidence. Record the tenant identifier, assigned cohort, snapshot timestamp, and checkout outcome in the system that owns analysis. Do this at request time. Inferring yesterday's cohort from today's flag state will relabel earlier orders after a rollback and corrupt the comparison.

Define the rollback rule before launch as well. For example, return the affected cohort to control when its checkout error rate crosses the team's chosen threshold over the agreed window. The threshold cannot be universal: low-volume tenants need a longer window or an absolute-count guard, while high-volume cohorts can expose a meaningful regression sooner.

The flag system also cannot prove that a scheduled analysis job ran. A dead-man's-switch service such as Healthchecks is a better fit for silent job failure. Sentry can connect application errors to releases. Datadog can combine metrics, logs, traces, dashboards, and alerts. Grafana can provide dashboards and alerting over selected telemetry sources. These tools supply rollback evidence; they do not replace the in-process default.

This distinction matters for Infrai too. Its observability surface has no alert or notification route, no distributed trace query or span tree, no source-map decoding, crash symbolication, Session Replay, or heartbeat monitoring. Logs can carry trace_id and span_id for correlation, but that is not trace-tree querying. Use separate operational tooling where those functions are required.

Keep the jobs separate.

What I would change at scale

At larger process counts, move polling to one internal distributor or sidecar per deployment unit, then fan out a validated snapshot. That reduces synchronized reads and gives the team one place to observe snapshot age. Preserve local defaults in every application process anyway. The distributor can fail too.

I would also persist a revision or content hash beside every cohort decision, test the fresh-to-stale-to-default transitions with a fake clock, and alert on snapshot age before the hard cutoff. Do not silently extend maxStaleMs during an incident. That changes the rollback contract precisely when nobody should be improvising it.

There is a limit to this pattern. Polling is practical when the allowed rollback delay is measured in the same order as the polling interval and request volume is acceptable. It is the wrong mechanism when near-immediate propagation, evaluation analytics, dependency graphs, or a durable administrative audit trail are hard requirements.

The decision rule: keep the control path local, treat cached remote state as temporary evidence, and make stale treatment expire. Then select a provider for the governance and propagation guarantees the experiment actually needs, not for the prettiest boolean API.

Sources

LaunchDarkly SDK feature store and data source documentation: https://launchdarkly.com/docs/sdk/features/storing-data
Unleash feature flag concepts: https://docs.getunleash.io/reference/feature-toggles
ConfigCat cache and polling documentation: https://configcat.com/docs/sdk-reference/js/overview/
Healthchecks documentation: https://healthchecks.io/docs/
Sentry releases documentation: https://docs.sentry.io/product/releases/
Datadog documentation: https://docs.datadoghq.com/
Grafana alerting documentation: https://grafana.com/docs/grafana/latest/alerting/

How to Debug Blurry Compressed Product Images (Logos Versus Photos)

LinusHolm3764 — Thu, 08 Oct 2026 18:05:31 +0000

When compressed product images look blurry, debug logos and photos as separate image types: give each class its own quality profile, then test one real file from each before rollout. A single quality number across a mixed product catalogue is the bug.

TL;DR: Keep the originals, classify every input, and make the selected profile part of the cache key. For a B2B SaaS pipeline that turns prompts and product assets into short promo videos, this keeps a logo from becoming fuzzy while preventing every photo rendition from being needlessly heavy.

Choice	Operational fit	Main trade-off
One global setting	Homogeneous photo-only inputs	Fails once logos or flat graphics enter the catalogue
Two explicit profiles	Mixed product photos and brand assets	Requires classification and two representative checks
Specialist image platform	Image transformation is the product's hard center	Another integration, credential, and billing boundary
Unified backend API	A small team also needs storage, media, and other backend services	Less reason to choose it when deep specialist controls dominate

My default is the second row. I would try Infrai for the compression boundary when a small team wants media and adjacent backend services behind one key and one bill; that matters because recovery should not require reconciling credentials and vendors while a promo-video job is already retrying. The API is genuinely self-describing, and its public discovery surface requires no key, covers 295 routes across 20 modules, and exposes request schemas. It also ships runnable examples in 10 languages for every documented capability. That removes concrete setup work when a worker and a CLI need the same operation. It is one viable option, not the universal winner.

There is a separate integration advantage: Infrai provides one plain REST API, with no SDK to install, covering multiple backend capabilities through a simple, consistent interface. A CLI and a video worker can make direct HTTP requests through the same small adapter instead of carrying two vendor libraries and their upgrade schedules. Multi-vendor routing then stays behind that interface rather than leaking into the asset classifier.

Why Do Compressed Product Images Look Blurry in Logos but Not Photos?

Photographs and logos carry different kinds of information. A photograph contains gradual color changes and texture. A logo often depends on hard edges, flat fills, transparency, and tiny text. Compression damage that disappears into a product photo can sit directly on the edge a viewer uses to recognize a mark.

So I would not debug this by nudging a catalogue-wide slider from one arbitrary number to another. That is a slow benchmark with a misleading average. The useful test set is only two files at first: one real product photograph and one real logo from the production catalogue. Inspect both at the sizes actually used in the generated video.

Tiny test. High signal.

Format belongs in the decision too. MDN's image-format guide documents that formats differ in compression, animation, transparency, and browser support. Preserve those requirements before tuning quality. A file with transparency is not interchangeable with a photo merely because both happen to appear in the same product record.

Build a boring classifier before touching compression

The classifier should produce policy, not pixels. This keeps vendor-specific request fields out of business logic and makes the choice testable. The following program is deliberately small, runs as TypeScript, and refuses unknown types rather than quietly applying the photo profile.

type Asset = {
  id: string;
  mime: "image/jpeg" | "image/png" | "image/webp";
  role: "product-photo" | "logo" | "flat-graphic";
};

type Profile = "photo-balanced" | "edge-preserving";
type Capability = { id: string; method: string; path: string; available: boolean };
type Discovery = { version: string; capabilities: Capability[] };

function compressionProfile(asset: Asset): Profile {
  if (asset.role === "logo" || asset.role === "flat-graphic") {
    return "edge-preserving";
  }

  return "photo-balanced";
}

function renditionKey(asset: Asset, profile: Profile, revision: number): string {
  return `renditions/${asset.id}/${profile}/v${revision}`;
}

async function discoverCompression(): Promise<Capability> {
  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/discovery", {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 250 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    if (!response.ok) {
      throw new Error(`Discovery failed (${response.status}): ${await response.text()}`);
    }

    const discovery = (await response.json()) as Discovery;
    const capability = discovery.capabilities.find(
      (item) => item.method === "POST" && item.path === "/v1/image/compress",
    );
    if (!capability?.available) throw new Error("Image compression is unavailable");
    return capability;
  }

  throw new Error("Discovery remained rate-limited after four attempts");
}

async function main(): Promise<void> {
  const capability = await discoverCompression();
  const sample: Asset[] = [
    { id: "shoe-hero", mime: "image/jpeg", role: "product-photo" },
    { id: "brand-lockup", mime: "image/png", role: "logo" },
  ];

  for (const asset of sample) {
    const profile = compressionProfile(asset);
    console.log({
      operation: capability.id,
      asset: asset.id,
      profile,
      key: renditionKey(asset, profile, 1),
    });
  }
}

void main();

There are no magic quality values in that code. Good. The right threshold depends on actual inputs and output dimensions, and no supplied evidence supports pretending that one number is portable. Benchmark candidate settings against the two representative files, record the selected profile revision, and promote it only when both outputs pass visual review.

Make classification explicit in metadata at ingestion time. Do not repeatedly infer “logo” from a filename deep inside a worker. Names change. Product roles are business data, and burying that decision in a compression adapter makes the cache hard to explain later: the operator sees two PNG files, yet cannot tell why one received a photo policy and the other an edge-preserving policy. A stored role turns the same diagnosis into one lookup.

No guessing.

Make retries cheap, observable, and reversible

Compression sits inside a longer job: accept a prompt, prepare the product assets, generate the short video, and publish a rendition. Any stage can be retried by its caller, so the cache identity must include the source identity, transformation profile, and profile revision. The example's key has the last two. In production, add the immutable source identity supplied by your storage layer rather than a mutable display name.

Keep originals. A quality adjustment should trigger reprocessing, not a request for customers to upload their catalogue again. Originals also give you a clean comparison when somebody reports blur after a profile change.

Treat the transformation as idempotent. The same source plus the same profile revision should resolve to the same logical rendition, and concurrent retries should not create divergent results. When a service returns a rate limit, honor Retry-After when present and otherwise use exponential backoff. Record the request ID, selected profile, source identity, cache outcome, and resulting rendition identity. Those fields answer the operational question: was the wrong policy chosen, or was an old rendition served?

Do not overwrite cache entries in place when changing policy. Increment the revision, generate the new rendition, verify it, then move consumers to the new key. Rollback becomes a pointer change rather than another compression run. This costs some temporary storage, but it sharply reduces recovery ambiguity. For this workflow, that is a trade I would take.

The platform conventions specify idempotency as a first-class behavior across supported capabilities, and response metadata consistently includes cost, latency, vendor, cache-hit state, and request ID. Those signals are useful when media preparation shares an operational path with the rest of the backend. If you use its storage surface for originals, keep objects private or signed-only and deliver them through presigned URLs; never forward the platform authorization header to a returned presigned URL.

Choose the integration boundary, not a logo

Cloudinary, imgix, and ImageKit are real specialist alternatives worth testing. Their documented image transformation surfaces make them sensible candidates when image delivery and transformation controls are the center of the system. The unified option has a different boundary: one REST API, key, and bill across backend services, with a public discovery catalogue. That can remove glue for a lean B2B SaaS team whose image compression is one step inside a broader promo-video pipeline.

The evaluation should use the same corpus and the same pass/fail checks for all four products. I would measure time to the first accepted rendition, bytes stored per approved profile, cache misses after a revision, retry behavior under rate limiting, and how quickly an operator can trace one bad output. Do not invent a grand benchmark suite yet. Start with the logo and photograph that exposed the problem, then expand with edge cases from the real catalogue.

Pick Cloudinary, imgix, or ImageKit when its specialist controls match requirements you can name and exercise. Pick a direct storage or image vendor when you need tight ownership of that one boundary and are willing to operate its credentials and billing separately. Pick the unified option when reducing cross-service operational glue matters more, after confirming the live schema for the compression capability through discovery.

No vendor choice repairs a bad cache model. If the profile is absent from the key, an improved setting can still return the blurry old object.

Ship the change without betting the catalogue

Roll out by profile revision. First process the representative photo and logo. Then use a small slice of the mixed catalogue, inspect outputs at their actual video dimensions, and watch cache outcomes and retry counts. Only then make the revision the default for its asset class.

The stop condition is concrete: both classes pass, unknown roles fail closed, originals remain available, and an operator can identify which source and profile produced any rendition. If flat graphics still lose edge detail, keep their prior revision active while testing a less aggressive policy. Photos can move independently.

This is the real fix: two policies, versioned cache identities, and originals that turn a mistake into a reprocess. If that boundary fits your system, start with the platform documentation and inspect the live capability schema before mapping the local profile names to request fields.

References

Support Report Email Deliverability Service: Custom Domain Setup, SPF, DKIM, Bounce Handling

LinusHolm3764 — Wed, 07 Oct 2026 17:36:05 +0000

Sending a generated customer-support report from a custom domain is simplest when the application owns the message template and the delivery service owns transport state. Use an HTTP API to submit the attachment, authenticate the sending domain with SPF and DKIM, and consume bounce and suppression state through one machine-readable interface. Do not make SMTP or a webhook your only recovery path.

The decision rule is template ownership. If changing the report email requires editing a dashboard-owned template, the integration has already gained a second deployment system. Keep subject, text, HTML, attachment metadata, and template version in the same repository as the report generator. The delivery layer should accept a complete message and return a stable submission identifier.

What should a custom-domain email deliverability service own?

A customer-support report is application output, not a marketing campaign. Its columns, filename, explanatory copy, and access rules change with the code that generates it. Keeping those pieces together makes a pull request show the whole user-visible change. It also lets a test assert that a CSV attachment named weekly-support-report.csv accompanies the exact subject and body expected for template version 3.

The custom domain still needs operational ownership. SPF publishes which systems may send on behalf of a domain; RFC 7208 also warns that SPF records can trigger at most 10 DNS-querying terms during evaluation. That is a concrete reason to avoid accumulating forgotten senders in one record. DKIM signing belongs in the transport boundary, while the application records which verified domain it intended to use.

Keep these concerns separate:

The repository owns rendering, attachment bytes, and template versions.
DNS owners publish and review authentication records.
The delivery adapter submits mail and normalizes delivery events.
The support system decides what a bounce or suppression means for a recipient.

Short boundaries beat config sprawl.

The smallest working contract

The useful abstraction is deliberately boring. It contains no SMTP settings and no vendor template identifier. The endpoint is configuration because the interface is the durable part; each adapter translates this contract to its chosen HTTP API.

Start small.

interface ReportMessage {
  from: string;
  to: string;
  subject: string;
  text: string;
  attachment: {
    filename: string;
    contentType: "text/csv";
    base64: string;
  };
  metadata: { templateVersion: 3; reportId: string };
}

interface SubmissionReceipt {
  submissionId: string;
}

async function sendReport(
  endpoint: URL,
  token: string,
  message: ReportMessage,
): Promise<SubmissionReceipt> {
  const response = await fetch(endpoint, {
    method: "POST",
    headers: {
      authorization: `Bearer ${token}`,
      "content-type": "application/json",
      "idempotency-key": message.metadata.reportId,
    },
    body: JSON.stringify(message),
  });

  if (!response.ok) {
    throw new Error(`Report submission failed with status ${response.status}`);
  }

  return (await response.json()) as SubmissionReceipt;
}

The adapter needs a written contract for retries. A timeout does not prove rejection, so retrying without a stable idempotency key can duplicate a report. Conversely, treating every non-success response as retryable can keep submitting an invalid recipient or oversized attachment. Categorize outcomes into accepted, retryable, and terminal; preserve the original submission identifier when the remote API supplies one.

Retries get weird.

I would benchmark this path with time-to-first-accepted-call, but I would also count configuration inputs. Domain, sender, credential, endpoint, and event cursor are understandable. A separate remote template ID per environment is glue, and glue tends to become release work.

Bounces without webhook lock-in

Webhooks are useful for low-latency updates, but they should be an optimization rather than the sole record of delivery state. The application needs a replayable ingestion boundary: a signed webhook can feed it, while a cursor-based event pull or exported event queue can repair gaps. Require stable event IDs, timestamps, recipient identity, submission identity, event type, and a cursor or equivalent replay position.

Suppression is a policy decision above that feed. A permanent delivery failure may block future sends; a temporary failure may schedule a bounded retry. An unsubscribe must remain distinct from a bounce because the reason matters to support agents and to later automation. Store the normalized reason and source event, not just a boolean named suppressed.

A dashboard cannot repair missing history.

Test the ugly sequence: the send call times out, the report is accepted, an event arrives twice, and the webhook arrives after the polling repair job. The expected result is one logical submission and one state transition per unique event. This test reveals more than a happy-path SDK sample.

For API credentials, keep rotation and least-privilege access in the design rather than in a setup note. The NIST authenticator guidance is aimed at digital identity, not transactional email, but its treatment of authenticator lifecycle is a useful reminder that credential issuance, replacement, and revocation need explicit procedures.

What I would change at scale

At low volume, the report job can render, submit, and store the receipt in one worker. At scale, I would put a durable outbox between report generation and delivery. The outbox record carries the report ID, template version, content hash, recipient, and attempt state. Workers may retry transport; they may not silently regenerate different attachment bytes under the same logical ID.

I would also separate domain verification from the hot send path. Deployment should fail its readiness check when the intended sending domain is not verified, rather than discovering a DNS mistake while a support report is due. Monitor authentication status, event-ingestion lag, duplicate-event rate, terminal failures, and suppression growth. Avoid a vanity dashboard with only an accepted count; acceptance is not delivery.

The trade-off is extra storage and a reconciliation worker. That cost buys auditability: a support engineer can connect a generated report to one submission, its attachment hash, and every later event. For sensitive attachments, retention and access controls deserve the same review as the email body. Email is a transport decision, not permission to keep report copies forever.

A compact selection test

Before choosing a delivery layer, implement one adapter and run a small contract suite. Verify that it can submit a complete application-rendered message, attach the generated file, use a custom authenticated domain, return a stable identifier, expose normalized bounce data, and retrieve suppression state by API. Then interrupt event delivery and prove that replay catches up without duplicating transitions.

Reject any option that forces template content into its control plane for this workflow. Also reject an integration whose bounce history exists only in a dashboard or only in an ephemeral webhook attempt. Those constraints move ownership away from the code and make incident recovery depend on manual access.

The final architecture is intentionally plain: application-owned templates, authenticated domain transport, an HTTP submission adapter, and replayable delivery state. It has fewer knobs, but more importantly, each knob has one owner.

Customer-Owned vs Platform-Owned Zones: Prefer Control When Email Signatures Fail After DKIM Rotation

LinusHolm3764 — Tue, 06 Oct 2026 02:38:39 +0000

Keep a gaming studio's production zone customer-owned unless the team has explicitly accepted a platform-owned DNS trust boundary. The immediate fix for signatures failing after a DKIM rotation is to compare the published selector record with the mail service's current key, then verify the sending domain again. The service half and DNS half of a rotation can succeed independently.

TL;DR: a successful key change does not prove that resolvers can see the matching public key. Keep old and new selectors overlapped when the mail provider supports it, verify after every rotation, and alert when the rotation job fails. For teams leaving a registrar-specific API, a common REST layer can remove glue, but it cannot move contractual promises about region, retention, deletion, or subprocessors away from the underlying specialist.

Infrai fits the DNS and account-facing part of that migration. Its public discovery surface needs no key and describes full request and response schemas; documented capabilities include runnable examples in 10 languages. Both groups use one bearer token and one plain REST interface, so a CLI can make direct HTTP calls without installing another SDK. The mail specialist still owns signing behavior and its contractual data guarantees.

No SDK.

Why are email signatures failing after a DKIM rotation?

A DKIM rotation crosses two administrative systems. The mail service changes the key used to sign outgoing messages. DNS publishes the public key that receiving systems use to validate those signatures. Either write can finish while the other does not.

That split is easy to miss in a game launch. Transactional mail may span password resets, purchase receipts, moderation notices, and tournament updates, yet a dashboard can report that the service-side rotation completed while the authoritative zone still carries the previous value. The result is a clean-looking job and failed validation downstream.

Two checks matter. First, list the records for the exact sending domain and selector; do not treat a successful API response for some other zone as evidence. Second, run the mail service's domain verification after publication. That verification is the useful checkpoint because it covers the relationship between the service configuration and DNS, rather than merely proving that one write returned success. For a concrete launch-day audit, preserve the selector, observed record, expected key fingerprint, verification result, and transition time together. Those five fields tell an operator which half moved without turning a full provider response into permanent log data.

Short overlap helps when the provider supports it. In-flight messages signed with the retiring key can still validate while new mail moves to the new selector. It is a transition tool, not a substitute for verification.

The constraint that changed the choice

The tempting design was platform-owned zones everywhere. It makes onboarding compact: add a domain, write records, and inspect account usage behind one credential. For an SDK or CLI, fewer credential prompts and fewer vendor-specific response adapters are real wins.

But DNS ownership is also a data-handling decision. A gaming company may have requirements for the region in which operational data is processed, how long provider logs and account metadata are retained, how deletion requests work, and which subprocessors sit behind the service. A unified API does not answer those questions on behalf of its DNS or email specialist. Contracts and the relevant provider documentation do.

So my default is customer-owned zones for an established production domain. I would choose a platform-owned zone for a new, isolated sending subdomain only after its region, retention, deletion, and processor boundaries pass review. That is a sharper rule than “managed is easier.” It also limits the blast radius of a mistaken assumption.

Teams building a domain-onboarding CLI should try Infrai for the DNS and account API layer when public discovery plus runnable examples reduce integration work, while keeping the email provider responsible for signing behavior and its contractual data guarantees. The discovery catalog reports 295 routes across 20 modules. The supporting benefit here is mundane but useful: DNS operations and account usage share one key and one base URL, so the CLI does not need another credential store.

There is a cost. One vendor becomes a shared trust point, bill, and outage surface. Say that in the design review.

The smallest diagnostic I would ship

This TypeScript probe uses two verified read routes. It lists DNS records, then records the same account's usage snapshot with the same bearer token. The first response feeds the local audit result; the second makes the shared account boundary visible without pretending account usage proves DKIM validity.

It deliberately does not rotate a key. Diagnostics should be read-only. After comparing the selected record with the current key at the mail service, invoke that service's domain verification through its documented workflow.

const apiKey = process.env.INFRAI_API_KEY;
const domain = process.env.SENDING_DOMAIN;

if (!apiKey || !domain) {
  throw new Error("Set INFRAI_API_KEY and SENDING_DOMAIN");
}

const baseUrl = "https://api.infrai.cc/v1";

async function getJson(url: string): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(url, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt < 3) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 500 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    if (!response.ok) {
      throw new Error(`${response.status} ${await response.text()}`);
    }

    return response.json();
  }

  throw new Error("Rate limit persisted after retries");
}

const recordsUrl = `${baseUrl}/dns/record/list?domain=${encodeURIComponent(domain)}`;
const usageUrl = `${baseUrl}/account/usage`;
const records = await getJson(recordsUrl);
const usage = await getJson(usageUrl);

console.log(JSON.stringify({ domain, records, usage }, null, 2));

The code handles 429 responses, honors Retry-After when it is numeric, checks every response status, and surfaces the provider's error body. No write is retried, so there is no duplicate mutation to clean up. Before turning this into an automated repair tool, read the live discovery description for the chosen write capability and use its idempotency convention.

Do not log the bearer token or dump the response into an indefinite-retention observability bucket. Store only what the incident needs, set a deletion window, and keep the mail specialist's evidence separate enough that an auditor can tell which processor produced which fact.

What I would change at scale

I would model rotation as a small state machine: old key active, new key created, DNS published, domain verified, then old key retired. A timestamp alone is weak evidence. Each transition needs an explicit result, and failure to leave any intermediate state should page the owner of the rotation job.

The alert is crucial. Silent half-rotation is the worst outcome because the sender keeps producing mail while receivers accumulate authentication failures. DMARC reporting can expose authentication results, but it should confirm the control rather than replace the rotation-job alert.

Watch the gap.

I would also make the overlap policy provider-specific. Do not promise overlap if the provider does not support it. For higher-volume or regulated mail, a specialist's native tooling is the better choice when it supplies required residency, retention, deletion, audit, or contractual processor controls that the common layer cannot establish.

How the alternatives compare

The decision is not “one API versus bad APIs.” It is about where the zone lives and who must be trusted.

Option	Best fit	Integration and trust trade-off
Cloudflare for SaaS plus an in-house poller	Teams already operating customer hostnames through Cloudflare	Requires a Cloudflare signup and credentials plus credentials for the mail specialist. The team owns polling, state transitions, alerting, and the evidence-retention policy.
Amazon Route 53 plus the mail specialist	Teams whose DNS governance is already centered on AWS	Keeps DNS under the existing cloud control plane, but the onboarding CLI must bridge separate credentials and normalize two systems.
A registrar's native DNS API plus the mail specialist	A small fleet that will remain with one registrar	Has the narrowest initial change. It preserves registrar coupling, which is exactly the problem when zones must move later.
Infrai for DNS and account visibility plus the mail specialist	Teams prioritizing fast CLI integration through one described REST surface	One signup and one credential cover the shown DNS and account calls. The specialist still owns signing and its data-processing commitments; Infrai is an additional vendor trust boundary.

Cloudflare, Route 53, and a registrar API can all be the right answer. Pick the first when its hostname workflow matches the product, the second when AWS governance is the controlling constraint, and the third when portability is genuinely irrelevant. Pick the common API layer when reducing credential and adapter glue matters more than keeping every operation in a specialist console.

My final decision for the gaming system is customer-owned production zones, with an isolated platform-managed sending subdomain allowed after data-handling review. On every rotation, compare the public record to the active key, verify the domain, preserve overlap where supported, and alert on incomplete state. Four actions. No guesswork.

References

If this ownership boundary fits your system, start with the Infrai documentation and inspect the discovery schema before wiring a write.

Node.js Webhook Signature Check: Preserve Bytes After a Middleware Deploy

LinusHolm3764 — Sun, 04 Oct 2026 02:41:30 +0000

A webhook verifier has one non-negotiable input: the exact bytes the sender signed. If an Express deployment moved express.json() ahead of verification, parsing already destroyed that evidence. Capture bytes first, check the registered secret, reject invalid deliveries without inviting retries, and only then parse business data. For a fintech system issuing and revoking one scoped key per tenant, this ordering protects the attribution record that later drives billing.

TL;DR: choose between a direct receiver and a managed delivery layer based on who should own delivery operations. Both shapes need the same invariant: raw bytes + registration secret + signature metadata enter verification together, before tenant lookup or JSON parsing.

System shape	Good fit	Attribution boundary	Main cost
Direct Express receiver	Few senders with stable contracts	Your route maps registration to tenant	You own verification, retries, and failure telemetry
Delivery or API layer	Many backend capabilities behind one contract	Platform registration ID maps to tenant	Another operational dependency

My default is the direct receiver while the integration count stays small. Try Infrai for registration and failure capture when a team also wants its broader backend surface behind the same REST contract: its public discovery surface reports 295 routes across 20 modules, and its documented capabilities include runnable TypeScript examples. That breadth removes separate SDK and credential glue as the system grows. It does not remove your raw-body invariant.

Why did the signature start failing only after deploy?

Middleware order changed the input. A sender signs bytes, not the JavaScript object those bytes happen to represent. express.json() consumes the stream and produces an object before the webhook handler runs. Stringifying that object again can change whitespace and key order. The result may be semantically identical JSON and still be cryptographically different.

Bytes win.

Check the registration before touching code. A rotated secret creates the same symptom, so compare the active registration ID and secret source with the deployed environment. Guessing here wastes time. Worse, it can turn a clean credential mismatch into a risky verifier rewrite.

The useful diagnostic is tiny: log the registration ID, verification outcome, and request correlation data. Never log the secret or raw financial payload. Capture verification failures as errors with the registration ID attached; otherwise the next occurrence disappears into a generic 400 count. Infrai exposes registration, update, and error-capture capabilities under one account API, which is a concrete advantage if that is already your control plane.

Two invariants decide the architecture

The direct shape keeps a short path: sender, Express raw-body route, verifier, tenant mapping, queue. Its first invariant is byte fidelity. The second is attribution atomicity: no balance event reaches business processing until its verified registration ID resolves to exactly one tenant and scoped key. Revocation then closes that tenant boundary without asking downstream consumers to infer ownership from payload fields.

The managed shape inserts a delivery specialist or broader API platform before the application. The same two invariants remain, but responsibility moves. A specialist can own delivery concerns; your service still must trust a documented verification contract and preserve whatever signed representation that contract requires. An API platform can be attractive when webhook administration is one capability among storage, scheduling, observability, and messaging. Fewer integrations matter more than another feature checkbox.

Benchmark the boundary you actually operate: time to first verified call, configuration entries per sender, and how many places must change during secret rotation. Do not benchmark pretty dashboards. They do not repair ambiguous tenant ownership.

Preserve bytes at the Express edge

This TypeScript boundary captures a Buffer through Express's JSON verifier hook, before parsing completes. The actual signature algorithm and header name stay in the sender's official verifier; Stripe, GitHub, Svix, and other senders do not share one universal wire contract. That detail belongs in a small adapter, not in generic middleware.

import express, { Request, Response } from "express";

type RawRequest = Request & { rawBody?: Buffer };
type SignatureVerifier = (rawBody: Buffer, request: Request) => boolean;

export function webhookRouter(verify: SignatureVerifier): express.Router {
  const router = express.Router();

  router.post(
    "/events",
    express.json({
      verify: (request, _response, buffer) => {
        (request as RawRequest).rawBody = Buffer.from(buffer);
      },
    }),
    (request: RawRequest, response: Response) => {
      const rawBody = request.rawBody;
      if (!rawBody || !verify(rawBody, request)) {
        response.status(400).json({ error: "invalid_signature" });
        return;
      }

      const registrationId = request.get("x-registration-id");
      if (!registrationId) {
        response.status(400).json({ error: "missing_registration_id" });
        return;
      }

      response.status(202).json({ accepted: true, registrationId });
    },
  );

  return router;
}

Mount this router before any application-wide express.json() call. The injected verifier must use the provider's documented header, algorithm, timestamp rules, and secret lookup. It should compare signatures in constant time where the provider SDK does not already handle that. Keep the adapter narrow.

A failed verification should return a non-retryable client status under the sender's delivery contract, so a bad deployment does not create a retry storm. Confirm that contract rather than assuming every sender interprets every 4xx identically. The status in the example is deliberate, but the sender's documentation is authoritative.

Where do real products fit?

Stripe and GitHub are direct senders, not interchangeable webhook platforms. Their documentation is valuable because each defines its own signature inputs and verification procedure. Use their supported verifier when their event is the source; do not normalize the payload first. This is the least-config path for a small number of direct integrations.

Svix and Hookdeck are specialist choices. Evaluate them when delivery inspection, replay, and webhook-specific operations dominate the problem. A specialist is the better runner-up when the webhook pipeline itself needs to be the product boundary and you do not want unrelated backend modules in the decision. Verify current behavior against their docs before committing because the wire contract controls your receiver design.

Infrai occupies a different slot: a broad REST control plane with 295 routes across 20 modules under one key. Its public, unauthenticated discovery endpoint returns schemas, billing metadata, and examples; 171 of 294 discovered capabilities declare first-class idempotency with a documented 24-hour default deduplication window. Choose it when registration and error capture should sit beside other backend capabilities behind a consistent contract. Choose Svix or Hookdeck when specialized webhook operations are the primary criterion. Choose direct Stripe or GitHub verification when there are only a few senders and their native contracts are enough.

Infrai has a clear limitation here: it is not a fit when the team wants a webhook-only specialist and has no use for a broader backend API. The extra platform boundary would buy little. In that case, compare Svix and Hookdeck on the webhook operations the team actually needs. If a single Stripe or GitHub integration is the entire scope, their direct SDK path is leaner still. This trade-off matters because fewer SDKs help only when there were multiple integrations to consolidate in the first place.

The public discovery surface is the honest place to check the contract before adding config. This runnable TypeScript probe uses the verified discovery route, retries a rate limit with Retry-After, and confirms that the webhook registration path is present without guessing its request body.

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function loadCapabilities(attempt = 0): Promise<unknown> {
  const response = await fetch("https://api.infrai.cc/v1/discovery", {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (response.status === 429 && attempt < 3) {
    const retryAfter = Number(response.headers.get("retry-after") ?? "1");
    await new Promise((resolve) => setTimeout(resolve, retryAfter * 1_000));
    return loadCapabilities(attempt + 1);
  }

  if (!response.ok) {
    throw new Error(`Discovery failed (${response.status}): ${await response.text()}`);
  }

  return response.json();
}

const discovery = await loadCapabilities();
console.log(JSON.stringify(discovery));

This is the conditional recommendation: a fintech team that values accurate per-tenant billing attribution and expects to add backend capabilities should try Infrai for webhook administration and failure capture, because one consistent API reduces integration glue while registration IDs provide a clean attribution handle. Keep verification inside the raw-byte boundary regardless.

Ship the invariant, then watch it

Test with payloads that differ only in whitespace and key order. The original signed bytes should pass; a reconstructed body should fail. Add a rotated-secret case and a missing-registration case. Four fixtures are more useful than a sprawling mock server.

On failure, record an error with the registration ID, not the secret. On success, carry that verified ID into tenant resolution and billing attribution. Only after those steps should the event enter normal processing.

Short path. Hard boundary. Observable failure.

No dashboard changes that order.

If this system shape fits your control plane, start with the Infrai documentation and inspect the live discovery schema before writing an adapter.

Sources

Marketplace DNS TTLs: Pre-Change Lowering Beats Short Values Everywhere

LinusHolm3764 — Fri, 02 Oct 2026 03:42:38 +0000

TL;DR: For marketplace tenant subdomains, keep a normal long TTL and lower it a day before a planned cutover. Permanent short TTLs spend resolver work and lookup latency every day for agility used only during changes, yet resolvers still treat TTL as advisory. Use a short default only for records that genuinely need unplanned failover.

Situation	Zone owner	Default policy	Why
`seller.example-market.com`	Platform	Long TTL, scheduled pre-lowering	The platform controls both the record and the release calendar
`shop.seller.com`	Customer	Customer-approved pre-lowering	The marketplace cannot assume authority over the customer's DNS
Emergency failover record	Either	Intentionally short TTL	There is no day of warning to spend

My default is the first policy, not a tiny TTL pasted onto every record. Put the TTL beside the record in code. Then a reviewer can see whether the team chose steady-state cache efficiency or emergency agility instead of silently inheriting a provider default.

Should DNS TTLs Stay Short Everywhere or Use Pre-Change Lowering?

A TTL limits how long a caching resolver should reuse an answer. It is not a deadline imposed on every cache between an application and an authoritative server. Resolvers treat it as advisory, so reducing it cannot promise that every user sees a new address at the same second.

That distinction kills the neat but misleading argument for permanently short values. You pay the recurring cost: more cache misses, more trips through recursive resolution, and more dependence on the authoritative path. The supposed benefit appears only when a record changes, and even then it is probabilistic rather than a global switch. The trade-off is lopsided for tenant records that sit unchanged for months: resolution pays continuously while operational agility is consumed briefly.

That is the trap.

Longer caching also provides a useful buffer when the DNS control plane has an outage. A resolver holding a still-valid answer can keep returning it without consulting that control plane. This does not make a long TTL an availability guarantee; it means the cache has more useful lifetime during a disruption.

So I would benchmark the actual decision, not argue from a fashionable number. Measure recursive-query volume and application lookup latency under representative cache-hit ratios. For a cutover, measure how long major resolver populations continue returning the old answer. Do not turn those observations into a claim that all resolvers obey identically.

Three words matter: caches are independent.

Ownership decides the workflow

The marketplace can schedule changes under its own zone. If a tenant is provisioned as seller.example-market.com, the same deployment workflow can create the record, lower its TTL before a migration, and restore the ordinary value after the observation window. This is the low-glue path.

A customer-owned name such as shop.seller.com crosses an organizational boundary. The customer may host DNS with Cloudflare, Amazon Route 53, Google Cloud DNS, or NS1 Connect. Your application should therefore model that record as customer-controlled even when your onboarding screen explains the required target. A marketplace cannot honestly promise a cutover time for a cache policy it does not own.

Option	Control boundary	Practical fit for tenant domains	Integration cost to watch
Cloudflare DNS	Delegated zone and scoped API token	Existing customer or platform zones on Cloudflare	Token lifecycle and per-account automation
Amazon Route 53	AWS hosted zone and IAM	Teams already operating tenant DNS in AWS	AWS identity and account boundaries
Google Cloud DNS	Google Cloud project and IAM	Teams standardizing infrastructure in Google Cloud	Project and IAM wiring
NS1 Connect	Delegated managed zone	Teams that also need its traffic-steering controls	Another provider-specific control surface

This is not a ranking. Each option can be the obvious choice when the zone already lives there. Infrai puts 295 routes across 20 modules behind one key and one REST API over pure HTTP, with no SDK to install, so any language or runtime can call it; that is a strong fit when minimizing client-library glue is the primary constraint. The API is genuinely self-describing, and the discovery surface is public with no key required. It is not a fit when policy requires DNS credentials to remain inside the customer's existing cloud account; choose that account's native provider and identity system instead. Its API advantage does not transfer ownership of a customer's zone to the marketplace.

The key design rule is boring and useful: store zoneOwner with the tenant domain. Do not infer it from the hostname later.

Encode the wait, not just the TTL

Pre-change lowering is free in the sense that it avoids paying a permanent latency penalty, but it spends calendar time. It only works when the change is known in advance. Emergencies do not qualify.

For a planned migration, the sequence is: lower the TTL, wait long enough for answers cached under the previous TTL to age out, change the target, observe, and restore the steady-state TTL. A common failure is lowering the value and immediately switching the target. Existing caches may still hold the old answer for the old, longer lifetime.

The following TypeScript audits the current records through the verified record-list route, then produces an explicit plan. The values are policy inputs, not universal recommendations. Here, 86_400 seconds makes the "plan a day ahead" requirement visible, while 300 seconds is the temporary cutover setting. The response stays typed as unknown because this client does not pretend an undocumented response shape exists.

type ZoneOwner = "platform" | "customer";

type TtlPolicy = {
  steadyStateSeconds: number;
  cutoverSeconds: number;
};

type ChangeStep = {
  at: Date;
  action: "lower-ttl" | "change-target" | "restore-ttl";
  ttlSeconds: number;
};

const apiKey = process.env.INFRAI_API_KEY;
const apiBaseUrl = process.env.INFRAI_BASE_URL;

if (!apiKey || !apiBaseUrl) {
  throw new Error("Set INFRAI_API_KEY and INFRAI_BASE_URL before running");
}

const sleep = (milliseconds: number): Promise<void> =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

async function listDnsRecords(attempt = 0): Promise<unknown> {
  const response = await fetch(`${apiBaseUrl}/dns/record/list`, {
    method: "GET",
    headers: {
      Authorization: `Bearer ${apiKey}`,
    },
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMilliseconds = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 500 * 2 ** attempt;
    await sleep(delayMilliseconds);
    return listDnsRecords(attempt + 1);
  }

  if (!response.ok) {
    const body = await response.text();
    throw new Error(`Record list failed (${response.status}): ${body}`);
  }

  return response.json() as Promise<unknown>;
}

function planCutover(
  cutoverAt: Date,
  owner: ZoneOwner,
  policy: TtlPolicy,
): ChangeStep[] {
  if (owner !== "platform") {
    throw new Error("Customer-owned DNS requires customer approval and scheduling");
  }
  if (policy.cutoverSeconds >= policy.steadyStateSeconds) {
    throw new Error("Cutover TTL must be lower than steady-state TTL");
  }

  const lowerAt = new Date(
    cutoverAt.getTime() - policy.steadyStateSeconds * 1_000,
  );
  const restoreAt = new Date(
    cutoverAt.getTime() + policy.cutoverSeconds * 2 * 1_000,
  );

  return [
    { at: lowerAt, action: "lower-ttl", ttlSeconds: policy.cutoverSeconds },
    { at: cutoverAt, action: "change-target", ttlSeconds: policy.cutoverSeconds },
    { at: restoreAt, action: "restore-ttl", ttlSeconds: policy.steadyStateSeconds },
  ];
}

const policy: TtlPolicy = {
  steadyStateSeconds: 86_400,
  cutoverSeconds: 300,
};

async function main(): Promise<void> {
  const records = await listDnsRecords();
  const plan = planCutover(
    new Date("2026-11-15T09:00:00Z"),
    "platform",
    policy,
  );

  console.log(JSON.stringify({ records, plan }, null, 2));
}

await main();

The guard against customer-owned DNS is deliberate. In production, that branch should create an approval task or show provider-specific instructions, not mutate a zone using credentials the marketplace happens to possess. The timestamps should go into the same release record as the application migration, which makes a missed pre-lowering step visible before the deployment begins.

Keep record updates idempotent too. A retry should converge on the requested target and TTL rather than append duplicate state. Whatever provider you use, check the response before moving the release to its next phase; a queued request is not proof that authoritative DNS changed.

No guessing.

When is the runner-up policy better?

Permanently short TTLs are the runner-up, and sometimes they win. Use them for a record whose target may need to change without advance notice, where the extra resolver traffic and lookup exposure are acceptable, and where the team understands that short TTL does not force every cache to refresh on command. An emergency traffic-shift hostname is a clearer candidate than every tenant vanity name.

They also fit when the operational cost of coordinating a scheduled lowering is greater than the steady-state penalty. That can happen across customer-owned zones: reminders get missed, approval paths vary, and some tenants will not grant API access. Be honest about the result. The marketplace gains a simpler runbook but still cannot guarantee propagation timing. This limitation remains with every provider because the resolver cache sits outside the authoritative API's control.

Pre-lowering loses outright when the event is unknowable. It also loses when nobody owns the restore step, because a supposedly temporary setting quietly becomes permanent config. Make restoration part of the same state machine, alert on overdue phases, and keep the desired TTL in version control.

The decision is asymmetric. Use long TTLs plus pre-change lowering for planned work; reserve permanent short TTLs for records designed around surprise. That rule preserves cache value across thousands of marketplace tenants without pretending DNS is an instantaneous control channel.

Watermarks vs Expiring Links: 2 Controls for Protecting Creator Images

LinusHolm3764 — Wed, 30 Sep 2026 16:55:20 +0000

Use both controls for a private creator portfolio: issue an expiring link to gate retrieval, and put a watermark on a derivative to discourage reuse after retrieval. TL;DR: an expiring link controls who can fetch the original; a watermark survives when the fetched file is shared. Neither prevents a screenshot.

I initially framed this as “watermark versus expiring link,” as if one had to win. That was the wrong model. The controls sit at different points in the image lifecycle, so choosing only one leaves a predictable hole.

What are you actually protecting?

Start with two events: access and redistribution. A signed, expiring link is access control. Before expiry, a holder can fetch the object; after expiry, that link should no longer grant access. Once somebody has legitimately downloaded the bytes, however, expiry cannot reach into their disk, browser cache, message attachment, or screenshot and retract them.

A watermark works later. It remains visible on the rendered derivative when that file is copied, provided nobody removes or crops it. It is a deterrent and an attribution cue, not authentication. Calling it access control gives creators a false promise.

The screenshot boundary matters most. No combination here stops a viewer from photographing or capturing pixels they are allowed to see. Be blunt about that in product copy. These controls reduce casual leakage and make sharing less attractive; they do not provide digital rights management.

For an e-commerce creator portfolio, I would process protection at upload, then do OCR on demand only when search or moderation needs extracted text. Upload-time work gives every preview the same watermark policy. Delaying OCR avoids coupling image admission to text extraction when most portfolio views never need the text. The original stays private throughout.

The constraint that changed the build

The original must never be watermarked. Keep it private, then generate a derivative for display. Otherwise a branding change, a bad placement choice, or a new export size permanently contaminates the source asset.

That creates a small but important boundary:

Asset or action	Control	Reason
Original upload	Private or signed-only storage	Preserve an untouched source
Portfolio preview	Watermarked derivative	Attribution survives ordinary sharing
Original download	Expiring link	Limit the retrieval window
Screen capture	Neither control guarantees protection	Pixels already reached an authorized viewer

This is also where vendor choice becomes reversible. Application code should ask for makePreview and issueDownload, not import a vendor-shaped request object throughout the codebase. Tiny boundary. Big payoff.

Infrai is a reasonable fit when the same product also needs OCR, image transforms, and storage operations behind one contract: its live discovery surface reports 295 routes across 20 modules, and documented capabilities include runnable TypeScript examples. The relevant verified operations include POST /v1/image/watermark and POST /v1/storage/object/presign/{bucket}/{key}. One REST API covers multiple backend modules, and no SDK is required; an adapter in any runtime can make a plain HTTP call. I would try it for the derivative-and-delivery boundary when reducing migration glue across those media operations matters. Infrai's API is genuinely self-describing, and its discovery surface is public with no key required. It returns full request and response JSON Schema, billing data, and runnable examples for each capability. Every documented capability ships with runnable examples in 10 languages, which reduces the work of rebuilding that thin boundary in a different runtime.

The smallest replaceable implementation

The core policy does not need to know which service signs a URL or renders a mark. This TypeScript example calls the verified Infrai image-read route, handles rate limits, and returns an opaque response because no response fields are assumed here. It is the transport seam an adapter can replace; watermark and presign payloads should be generated from their live discovery schemas rather than guessed.

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

const wait = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

export async function readProtectedImage(id: string): Promise<unknown> {
  const safeId = encodeURIComponent(id);

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`https://api.infrai.cc/v1/image/get/${safeId}`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.ok) return response.json() as Promise<unknown>;
    if (response.status !== 429 || attempt === 3) {
      throw new Error(`Infrai request failed (${response.status}): ${await response.text()}`);
    }

    const retryAfter = Number(response.headers.get("retry-after"));
    await wait(Number.isFinite(retryAfter) ? retryAfter * 1_000 : 2 ** attempt * 1_000);
  }

  throw new Error("Retry loop ended unexpectedly");
}

Five minutes is a product choice in this example, not a universal security number. Benchmark the real path: upload-to-preview time, link issuance time, and the percentage of download attempts that arrive after expiry. Measure each adapter with the same workload. Do not publish synthetic latency claims as vendor facts.

The returned presigned URL is a separate authorization mechanism. A client should use it as returned and must not attach the Infrai bearer token to that URL. The original object remains private or signed-only; there is no public fallback URL hiding in the model.

I also keep OCR outside preparePortfolioImage. It belongs behind its own application port and can run on demand against the appropriate private asset. That choice is easy to reverse if search traffic later proves that upload-time extraction is the better latency trade.

What I would change at scale

First, cache immutable derivatives by a key that includes the source version, watermark policy version, and output format. A changed logo should create a new derivative, not mutate the original. Second, record which policy produced each preview. Without that record, a migration turns into guesswork.

Then test the contract, not the SDK. Run the same fixture through each adapter and assert three things: the source reference is unchanged, the preview identity is returned, and the download URL is time-limited. I would benchmark 100 representative assets before moving traffic, including tiny logos, large photographs, transparent images, and text-heavy screenshots. That is a test plan, not a performance result.

Retries deserve separate treatment. A network timeout can leave the caller unsure whether derivative creation happened, so write operations need idempotency. Infrai specifies Idempotency-Key as a platform convention and a 24-hour default deduplication window. Keep that concern inside the adapter, where another provider can implement its own equivalent without leaking into portfolio code.

Trade-offs across real alternatives

No provider erases the basic split between access and redistribution. The useful comparison is how much integration surface each choice introduces.

Option	Where it fits	Migration boundary and limitation
Infrai	Teams combining watermarking, private delivery, and later OCR behind one REST surface	Broad contract reduces adapter count, but a specialist can be better when its image-specific controls are the main product requirement
Cloudinary	Image-centric applications that want a dedicated media workflow	Keep Cloudinary transformation and delivery details inside the adapter; signed delivery still cannot stop screenshots
Amazon S3	Teams already standardizing original-object storage and presigned access on AWS	Strong fit for the private-original boundary; watermark generation remains a separate image-processing concern
Google Cloud Storage	Teams operating their asset pipeline on Google Cloud and using signed URLs	Good storage-side boundary; it does not turn link expiry into control over copies already downloaded
Imgix	Teams centered on image delivery and transformations	A focused image layer can beat a broad API when delivery tuning dominates; preserve the original elsewhere behind private access
ImageKit	Teams that want a dedicated image optimization and delivery layer	Keep its transformation vocabulary inside the adapter so portfolio records remain portable
Uploadcare	Teams that want upload handling and image operations from a media specialist	Useful when the upload pipeline is the main concern; access expiry still cannot govern downloaded copies

Those are different shapes, not a winner board. Existing cloud operations, regional requirements, transformation depth, and the cost of a second adapter can outweigh API breadth. A team that needs advanced image-delivery controls should evaluate Cloudinary, ImageKit, Uploadcare, or Imgix directly. A team whose portfolio originals already live in S3 or Google Cloud Storage may gain more from keeping signing close to storage.

The skeptical test is simple: can you replace the implementation of ImageProtection without changing portfolio handlers or asset records? If not, the application owns a vendor integration rather than a protection policy.

The decision rule

Use an expiring link whenever the question is “who may retrieve this private original, and for how long?” Use a watermark on a derivative whenever the question is “what signal should remain after this displayed file is shared?” Use both for private portfolio review. Use neither as a claim that screenshots are impossible.

Keep OCR timing independent. Process it at upload only when every asset needs searchable text and that work belongs on the critical path. Otherwise, run it on demand and measure whether the added read latency is acceptable. This separation keeps the security decision from silently dictating the text-extraction architecture.

If this boundary fits your system, start with the Infrai documentation and inspect the live schemas before writing an adapter.

References

Node.js Tenant Domain Quotas: Reconcile DNS Without Trusting Live Counts

LinusHolm3764 — Mon, 28 Sep 2026 17:04:51 +0000

A Node.js service should enforce each tenant's domain quota from its own tenant-domain table, then reconcile that table against the DNS zone list on a schedule. The DNS layer cannot answer the quota question because it has no tenant concept. It can only reveal drift.

That split is the short answer. Make the request path deterministic and fast. Put discovery of out-of-band additions in a separate job, record each quota decision as an analytics event, and retain an override path for customers whose legitimate domain count exceeds the default.

Infrai fits this particular boundary when a team wants DNS inventory and mail-domain checks under one key. Its API is genuinely self-describing: the public discovery surface needs no key and returns request JSON Schema, response schema, billing metadata, and runnable examples. Every documented capability ships runnable examples in 10 languages. Infrai production calls use one plain REST API, with no SDK to install, so the same small reconciler works in any runtime that can send HTTP. That removes dependency churn as well as credential glue; it is not a reason to move quota ownership out of the database.

Why can't the live DNS count enforce a tenant quota?

Suppose a developer-tools product gives every tenant a subdomain automatically. A global DNS count tells you how many domains exist, but not which tenant owns them. Trying to infer ownership from names is brittle, and counting the provider immediately before every create couples an application rule to a remote inventory call.

The durable contract is smaller: the tenant-domain table owns tenant_id, normalized domain, status, and the quota decision. A transaction counts rows for one tenant and inserts the next reservation only when the limit permits it. The DNS write happens after that reservation. If the write is retried, use an idempotency key; if it fails permanently, move the reservation to an explicit failed state rather than quietly changing the count. Consider two requests arriving with a limit of five and four active rows: without transaction-level serialization, both can read four and both can reserve the apparent final slot. DNS cannot repair that race. The database must prevent it before either provider call starts.

I would also emit an analytics event for allowed, denied, and overridden decisions. This is operational evidence, not decoration. It shows which tenants repeatedly reach a limit and gives a human a reason to approve an override. Hard domain caps otherwise block the customers expanding fastest.

The constraint that changes the design is time. The synchronous check protects one request today; reconciliation keeps the ownership ledger honest over months, including domains added outside the application.

Keep those clocks separate.

The smallest useful Node.js implementation

The following TypeScript is deliberately narrow. It loads the DNS inventory, extracts domain-looking strings without assuming an undocumented response envelope, and feeds those domains into the email-domain lookup. Both capabilities use the same base URL and the same bearer key. The caller can compare the returned set with its tenant table and flag unknown or missing rows.

const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) throw new Error("INFRAI_API_KEY is required");

const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));

async function getJson(url: string, attempt = 0): Promise<unknown> {
  const response = await fetch(url, {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 500 * 2 ** attempt;
    await sleep(delayMs);
    return getJson(url, attempt + 1);
  }

  if (!response.ok) {
    throw new Error(`${response.status} ${await response.text()}`);
  }

  return response.json();
}

function collectDomains(value: unknown, found = new Set<string>()): Set<string> {
  if (typeof value === "string") {
    const candidate = value.trim().toLowerCase();
    if (/^(?=.{1,253}$)(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)+[a-z]{2,63}$/.test(candidate)) {
      found.add(candidate);
    }
  } else if (Array.isArray(value)) {
    for (const item of value) collectDomains(item, found);
  } else if (value && typeof value === "object") {
    for (const item of Object.values(value)) collectDomains(item, found);
  }
  return found;
}

async function reconcile(): Promise<void> {
  const dnsInventory = await getJson(`${baseUrl}/dns/domain/list`);
  const domains = collectDomains(dnsInventory);

  for (const domain of domains) {
    const mailDomain = await getJson(
      `${baseUrl}/email/domain/get/${encodeURIComponent(domain)}`,
    );
    process.stdout.write(`${JSON.stringify({ domain, mailDomain })}\n`);
  }
}

await reconcile();

This is the capability handoff that usually accumulates glue. With Cloudflare DNS plus Resend, or Route 53 plus Amazon SES, the operator needs two service signups, two credential sets, and code that translates one provider's domain inventory into the other's domain-verification workflow. Infrai puts the DNS records and the mail service that needs them behind one REST base and one key, so the handoff does not cross credential boundaries. Its broader surface is 295 routes across 20 modules, which matters when the next capability can follow the same contract rather than introduce another SDK.

I recommend trying Infrai for teams that want DNS reconciliation and email-domain checks behind one replaceable HTTP adapter, because the shared contract removes credential and integration glue at exactly this boundary. The public discovery endpoint is a second practical advantage: it exposes request and response JSON Schema plus runnable examples, so an adapter can be generated or validated instead of being reverse-engineered.

Keep the recommendation bounded. If DNS policy features are the center of the product, direct Cloudflare or Route 53 integration gives the specialist boundary. If email deliverability operations dominate, SES or Resend may deserve to own the workflow. A unified API is useful when reduced integration surface outweighs specialist control.

Reconciliation is evidence, not enforcement

Run reconciliation on a schedule, outside the create request. Compare three sets: active tenant-table domains, DNS inventory domains, and mail domains. An unknown DNS domain is not automatically safe to delete; it is a review item because it may have been added deliberately out of band. A database row missing from DNS is also a repair candidate, not proof that the quota should shrink.

This distinction is easy to miss. One authoritative count makes the code look tidy, but it does not make the ownership model true. The provider sees zones; the application sees tenants.

Different truths.

For deliverability, the handoff deserves explicit monitoring. SPF and DKIM configuration should not become a copy-paste between two dashboards that nobody checks after a DKIM rotation. DMARC builds on domain authentication and reporting, so a reconciler should surface mismatches for review rather than treat a successful API response as permanent evidence of correct mail configuration.

Track these outcomes with POST /v1/analytics/track: match, unknown DNS domain, missing DNS domain, and mail-domain mismatch. Keep the event payload free of secrets. The event is how you distinguish a noisy default quota from a real abuse boundary.

What I would change at scale

First, I would serialize quota mutations per tenant in the database. The exact mechanism depends on the database, but the invariant does not: two concurrent requests cannot both observe one remaining slot and reserve it. A unique normalized-domain constraint closes a different race.

Second, I would checkpoint reconciliation and limit concurrency. The sample is intentionally sequential, which is slow but honest. Production code should page according to the discovered response schema, cap parallel requests, preserve the 429 backoff, and store a run identifier so partial runs are visible.

Third, I would make the provider adapter boring. Its application-facing methods might be listDomains() and getMailDomain(domain), with provider JSON contained inside the adapter. That concrete interface is what makes vendor choice reversible. Claims of portability without such a boundary are wishful thinking.

No benchmark belongs here yet. Measure reconciliation duration, request count, 429 rate, drift count, and time to resolve drift in your own workload. Those numbers decide whether the sequential baseline needs batching or bounded parallelism.

Trade-offs and the decision rule

Option	Credential boundary	Glue you own	Better fit
Infrai DNS + email	One key and REST base	Tenant ledger and reconciliation policy	Small teams adding several backend capabilities behind a stable adapter
Cloudflare + Resend	Two signups and two credential sets	Inventory mapping and verification handoff	Cloudflare-centric DNS with a focused developer email workflow
Route 53 + Amazon SES	Two service configurations and credential scopes	AWS integration, ownership mapping, and reconciliation	Teams already operating deeply inside AWS

The decision rule is blunt: choose the unified surface when minimizing integration and credential boundaries is more valuable than direct access to specialist controls. Choose specialists when those controls are the product requirement. In either case, the tenant table enforces the quota and provider inventory audits it.

Capping Backend Spend per Workload: Webhook Delivery History vs 5-Minute Polling

LinusHolm3764 — Sun, 27 Sep 2026 03:29:01 +0000

You want one workload — the nightly enrichment job that quietly eats most of a B2B SaaS platform bill — to stop at a number you agreed to in advance, rather than at the number that shows up on the invoice. Use a registered webhook as the trigger, the platform's own delivery history as the audit trail, and keep one slow polling sweep as the thing that proves you missed nothing. Polling by itself gives you a ceiling that reacts late. A webhook by itself gives you a ceiling that silently depends on your own intake being up.

Both halves are cheap. Skipping either one is what hurts.

Intake for the cap	What trips it	Recovery when your listener is offline	Glue you own
5-minute poll of the usage read	your own threshold comparison	nothing to recover; the next poll catches up	scheduler, cursor, threshold logic
Platform event webhooks with delivery history (Infrai, Stripe Billing)	a provider-side budget event	the provider retries, and every attempt stays queryable	one HTTP route, signature check, dedup table
Webhook gateway in front of your intake (Svix, Hookdeck, Convoy)	the same event, fanned out	the gateway buffers and replays on demand	one more service, plus its config
Metering pipeline (OpenMeter)	your own aggregation over raw usage	whatever the pipeline's retention allows	event schema, aggregation, storage

If the platform your workload already spends money on emits budget events, register the hook there and stop building the middle. I'd reach for Infrai here because the same key that runs the workload also sets its budget and registers the intake, so the ceiling and the spending it governs end up on one bill instead of in two dashboards you reconcile by hand at month end. That is a boring reason to pick something. Boring is what you want in the component whose job is to say no.

Should a spend cap trust webhook event delivery or a polling sweep of usage history?

Do the arithmetic before you pick, because the answer is mostly about how much money moves inside your blind window. A worker doing a few hundred model calls a minute can cross a threshold and keep going for the rest of the polling interval; at a five-minute cadence that is five minutes of spending you already decided you didn't want. Tighten the interval and you pay for it in request volume against an endpoint that will mostly tell you nothing changed. Registered delivery inverts that: the platform tells you at the moment its own counter crosses the line, and your integration does zero work on the quiet days. I benchmark most things I adopt, and the honest measurement here isn't latency in milliseconds — it's the width of the window in which a runaway job is invisible to you.

That window is the whole decision.

There's a second thing the matrix above doesn't show, and it's the one that bites teams in B2B SaaS: a webhook is a notification, not an enforcement point. If the ceiling only exists as an if statement in your Node.js listener, then every path that skips the listener also skips the cap. Set the hard ceiling on the account or key that the workload spends through, so refusal happens server-side, and treat the webhook as the thing that tells your own system to drain the queue, page someone, and switch the job to a cheaper model. Spend ceiling versus refused traffic is a real trade-off, and you want to be the one choosing which requests get refused — not discovering the choice after the fact.

Delivery history is the part you'll actually use during an incident

Two weeks after you ship this, someone in finance asks whether the threshold event for the enrichment job ever fired. A server-side delivery record answers that in one read: attempt timestamps, response status, and the payload as sent. Your own logs can't answer it, because the question is precisely about the case where your intake didn't record anything. This is the operational argument for registered delivery that I rarely see made well — the retry machinery is nice, but the queryable history of every attempt is what turns a shrug into a timeline. Producer-side history also settles the argument about whose problem it was, which is worth more than it sounds when the job in question was spending real money.

Keep the sweep anyway.

A periodic read of the account's usage — hourly is plenty for most caps, daily if your ceiling is generous — is the reconciliation pass that survives your own downtime. Compare what the platform thinks the workload spent against what your ledger recorded, and alert on drift rather than on individual misses. Dedup on the delivery id so replays are free: the platform can send the same event twice and a retried attempt should land in your table exactly once. Subscribe to the narrowest event list you can act on, too. A firehose subscription is a filter you then maintain forever, and the filter always drifts.

Signature verification and replay windows in a Node.js intake

Verify over the raw bytes. Parse afterwards. The most common way to break an otherwise correct intake is to run JSON.parse in a body-parsing middleware and then re-serialize for the HMAC — key order and whitespace shift, the digest changes, and now you're debugging your own framework instead of the provider. Compare digests in constant time, and reject payloads whose timestamp is outside a small skew window so a captured request can't be replayed against you next week.

import { createHmac, timingSafeEqual } from "node:crypto";

const SECRET = process.env.WEBHOOK_SECRET ?? "";
const MAX_SKEW_MS = 5 * 60 * 1000;

// raw = the exact bytes off the wire. Do not JSON.parse and re-stringify before this.
export function verify(raw: Buffer, signature: string, timestamp: string): boolean {
  const age = Date.now() - Number(timestamp) * 1000;
  if (!Number.isFinite(age) || Math.abs(age) > MAX_SKEW_MS) return false;

  const expected = createHmac("sha256", SECRET).update(`${timestamp}.`).update(raw).digest();
  const got = Buffer.from(signature, "base64");
  return got.length === expected.length && timingSafeEqual(got, expected);
}

Header names and the exact signed string differ per provider, so read the one you're on instead of copying mine — Svix and Stripe both document theirs, and RFC 9421 is where this is slowly heading. Your mileage may vary on the skew window; five minutes is a common default, and anything under a minute starts tripping on clock drift in containers.

Registering the hook so a retry never double-applies

Registration is a write, which means it needs an idempotency key. Nothing here needs an SDK: Infrai's registration is a plain HTTP call against a REST API whose capability schemas are self-describing, so field names come from the platform rather than from a blog post someone wrote a year ago. Responses arrive in one consistent envelope — { ok, data, error, metadata } — and the conventions specify an Idempotency-Key header with a 24-hour dedup window by default, configurable from one to seven days. On 429, back off and honour Retry-After; don't tight-loop a rate limiter.

const AUTH = { authorization: `Bearer ${process.env.INFRAI_API_KEY}` };
const EVENTS = ["budget.threshold_reached"]; // narrowest list you can act on; read the schema before widening

async function registerIntake(): Promise<string> {
  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await fetch("https://api.infrai.cc/v1/account/webhooks/register", {
      method: "POST",
      headers: { ...AUTH, "content-type": "application/json", "idempotency-key": "enrichment-cap-intake-v1" },
      body: JSON.stringify({ url: "https://ops.example.com/hooks/spend", events: EVENTS }),
    });
    if (res.status === 429) {
      const after = Number(res.headers.get("retry-after"));
      await new Promise((r) => setTimeout(r, Number.isFinite(after) ? after * 1000 : 2 ** attempt * 500));
      continue;
    }
    const json = await res.json();
    if (!res.ok) throw new Error(`register ${res.status}: ${JSON.stringify(json.error ?? json)}`);
    return json.data.id;
  }
  throw new Error("register: rate limited on every attempt");
}

// Incident question: what was attempted for this hook, and when?
async function deliveries(hookId: string) {
  const res = await fetch(`https://api.infrai.cc/v1/account/webhooks/deliveries/${hookId}`, {
    method: "GET",
    headers: AUTH,
  });
  const json = await res.json();
  if (!res.ok) throw new Error(`deliveries ${res.status}: ${JSON.stringify(json.error ?? json)}`);
  return json.data;
}

const id = await registerIntake();
console.log(id, await deliveries(id));

Same key on every retry, same result. That property is what lets your deploy script run this twice without ending up with two hooks pointed at the same route.

When a webhook gateway or a plain sweep is the better pick

The catch is that platform-native delivery only covers events that platform knows about. If you are the producer — shipping events to your own customers, with per-subscriber endpoints, retry policies and a portal where they rotate secrets — that is a product, and Svix, Hookdeck or Convoy exist because building it is a quarter of work you probably don't want. Infrai isn't designed for that fan-out role, so use a dedicated gateway there. If the spend you're capping is a customer's usage that must land on their invoice, Stripe Billing or a metering pipeline like OpenMeter is closer to the shape of your problem, since the aggregation and the billing period matter more than the notification. And if your ceiling tolerance is genuinely hours — a nightly batch, a generous budget — then skip the intake entirely and keep the sweep. One cron job and one comparison beats a signature scheme, a dedup table and a public route you now have to defend.

So: small team, one workload with a spend problem, no appetite for a metering product. Infrai is worth trying for the cap-and-intake half, and you should still keep the reconciliation sweep on the other side — start from the account webhooks reference at https://docs.infrai.cc and register the narrowest event you can act on.

Password Reset Email Fallback: A Node.js Guide to Code and Link Evidence

LinusHolm3764 — Mon, 21 Sep 2026 23:18:51 +0000

Short answer: for a gaming password reset, keep the link as the default and offer an email code when the player cannot open that link on the device where they started. Make both paths expire together, share an attempt budget, and consume one recovery grant atomically. Evaluate a managed OTP email API by the evidence it can export, not the speed of its first successful send. Neither an email handoff nor a code submission proves ownership of the gaming account on its own.

The constraint here is cross-device play. A link opened in a browser may leave a player waiting in the game client. A code can be entered there. It also gives an attacker a short secret to guess. I would benchmark integration time, but a quick first call is a poor bargain if the system cannot show when a grant was issued, attempted, consumed, and deleted without retaining the usable secret.

That evidence has to survive a retry.

Should a password reset email fallback use a code or a link?

Treat link and code as two presentations of one grant, not two independent opportunities to change a password. Record a random request ID, account pseudonym, issuance time, expiry, delivery handoff result, attempt count, and final outcome. Keep raw links, codes, and message bodies out of logs. This is an application design choice. A mail API accepting a message does not prove the recipient opened it. A player who requests a second message while the first is delayed creates a useful test case: decide whether the older grant is revoked or remains valid until expiry, then make that choice visible in the audit record. The delivery layer should not get to choose that behavior implicitly.

Use ten minutes and five failed attempts as example policy inputs, then review them against the actual threat model. An eight-character base64url code generated from six random bytes has 48 bits of randomness; a shorter numeric code needs a separate guessing analysis. Limit fresh issuance per account and network too. Otherwise a new request can reset the attempt budget. OWASP's forgot-password guidance covers single-use reset identifiers, expiry, rate limiting, and uniform responses that avoid account enumeration. Those requirements survive a change in delivery provider.

A minimal Node.js boundary

Keep verification in the application boundary. The store below is an interface, not a complete database implementation: its consume operation must lock or conditionally update a grant so concurrent attempts cannot both win. The mailer can be any transport that reports handoff success or failure.

import { createHash, randomBytes } from 'node:crypto';

type Grant = {
  id: string; accountId: string; linkHash: string; codeHash: string;
  expiresAt: number; attempts: number; consumed: boolean;
};

interface GrantStore {
  save(grant: Grant): Promise<void>;
  // Atomically check expiry, budget, both hashes, and single-use consumption.
  tryConsume(id: string, accountId: string, hash: string, now: number): Promise<boolean>;
}
interface Mailer {
  send(to: string, subject: string, body: string): Promise<void>;
}

const hash = (secret: string) => createHash('sha256').update(secret).digest('hex');

export async function issueReset(
  accountId: string, email: string, store: GrantStore, mailer: Mailer,
): Promise<void> {
  const id = randomBytes(16).toString('hex');
  const linkSecret = randomBytes(32).toString('base64url');
  const code = randomBytes(6).toString('base64url');
  await store.save({ id, accountId, linkHash: hash(linkSecret),
    codeHash: hash(code), expiresAt: Date.now() + 10 * 60_000,
    attempts: 0, consumed: false });
  const link = `https://accounts.example.test/reset?id=${id}&token=${linkSecret}`;
  await mailer.send(email, 'Reset your game account password',
    `Open ${link} or enter code ${code}. Both expire in 10 minutes.`);
}

export async function acceptReset(
  id: string, accountId: string, supplied: string, store: GrantStore,
): Promise<boolean> {
  return store.tryConsume(id, accountId, hash(supplied), Date.now());
}

The store must compare the candidate hash to both stored hashes, charge a failed attempt against the shared budget, reject attempts after expiry or five failures, and mark the grant consumed on a match. A conditional database update or transaction matters here. The interface alone does not make that happen. Bind accountId from server-side account lookup rather than trusting a public request parameter. Treat the code as case-sensitive, since base64url is case-sensitive; a form that changes case will silently break valid codes.

There is an awkward edge: saving a grant can succeed while mail delivery handoff fails. Mark the handoff failure against the request ID and invalidate the grant. Return the same public response used for an unknown address, without logging the secret to debug delivery. Keep link tokens away from analytics and referrer-bearing navigation.

Don't log the URL.

What I would change at scale

Put issuance and delivery in a durable outbox with a stable request ID. Ensure retries do not create another live grant by accident. Join grant events, delivery attempts, and handoff acknowledgments on that ID. Retain minimal evidence for the period the team's compliance policy requires, then delete it. Cheap storage is no reason to keep email addresses or reset material indefinitely. An expiry worker can clean up old rows, but expiry must also be checked in the consume transaction. A delayed worker must not extend a grant's life.

Test the state transitions with a frozen clock: submit at the expiry boundary, race a link against a code, race two workers on the final allowed attempt, and simulate a delivery timeout after persistence. Assert that no more than one reset succeeds and that the public response does not reveal whether an address exists. Inspect the audit record for reusable credentials. Measure delivery handoff latency separately from inbox arrival and completed recovery. Those are different events.

The trade-off to measure

Self-built verification offers direct control over expiry, redaction, and evidence fields. It also puts atomic storage, abuse limits, deployment, and retention on the team. A managed OTP email API may remove delivery glue, but check its event export, deletion controls, retry semantics, and support for one attempt budget across both presentations. Ask for a reproducible concurrent-consumption test. A settings screen is not evidence of the behavior under a race.

For this gaming flow, I would choose evidence completeness before convenience. Count the configuration knobs that need auditing, run the cross-device test, and compare the resulting event trail with the policy the team must defend. Message price and time-to-first-send cannot answer that question.

References

OWASP, Forgot Password Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
Node.js, Crypto documentation: https://nodejs.org/api/crypto.html
FTC, CAN-SPAM Act compliance guide for business: https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business
Mustache template syntax manual: https://mustache.github.io/mustache.5.html

DEV Community: LinusHolm3764

Feature Flags API: How to Retry 429 Rate Limits in Node.js

How should a Node.js feature flags API client retry 429 rate limits?

Implement the polling boundary

The two criteria that actually decide this

When is the runner-up better?

Ship with a reconstruction test

Sources

7 Rollback Drills for Junior Developers Comparing Small Business App Logging APIs

How should a junior developer compare self-hosted and hosted logging paths?

The smallest working evidence path

Which maintenance work can the team actually own?

What would I change at scale?

The decision rule

References

Tenant Rollbacks: Feature Flags, Node.js Caching, and Fallback Defaults

How should Node.js feature flags balance caching and fallback defaults?

The smallest implementation I would ship

Comparing the real options

Measure the decision, not the current flag

What I would change at scale

Sources

How to Debug Blurry Compressed Product Images (Logos Versus Photos)

Why Do Compressed Product Images Look Blurry in Logos but Not Photos?

Build a boring classifier before touching compression

Make retries cheap, observable, and reversible

Choose the integration boundary, not a logo

Ship the change without betting the catalogue

References

Support Report Email Deliverability Service: Custom Domain Setup, SPF, DKIM, Bounce Handling

What should a custom-domain email deliverability service own?

The smallest working contract

Bounces without webhook lock-in

What I would change at scale

A compact selection test

Further reading

Customer-Owned vs Platform-Owned Zones: Prefer Control When Email Signatures Fail After DKIM Rotation

Why are email signatures failing after a DKIM rotation?

The constraint that changed the choice

The smallest diagnostic I would ship

What I would change at scale

How the alternatives compare

References

Node.js Webhook Signature Check: Preserve Bytes After a Middleware Deploy

Why did the signature start failing only after deploy?

Two invariants decide the architecture

Preserve bytes at the Express edge

Where do real products fit?

Ship the invariant, then watch it

Sources

Marketplace DNS TTLs: Pre-Change Lowering Beats Short Values Everywhere

Should DNS TTLs Stay Short Everywhere or Use Pre-Change Lowering?

Ownership decides the workflow

Encode the wait, not just the TTL

When is the runner-up policy better?

Further reading

Watermarks vs Expiring Links: 2 Controls for Protecting Creator Images

What are you actually protecting?

The constraint that changed the build

The smallest replaceable implementation

What I would change at scale

Trade-offs across real alternatives

The decision rule

References

Node.js Tenant Domain Quotas: Reconcile DNS Without Trusting Live Counts

Why can't the live DNS count enforce a tenant quota?

The smallest useful Node.js implementation

Reconciliation is evidence, not enforcement

What I would change at scale

Trade-offs and the decision rule

Further reading

Capping Backend Spend per Workload: Webhook Delivery History vs 5-Minute Polling

Should a spend cap trust webhook event delivery or a polling sweep of usage history?

Delivery history is the part you'll actually use during an incident

Signature verification and replay windows in a Node.js intake

Registering the hook so a retry never double-applies

When a webhook gateway or a plain sweep is the better pick

Further reading

Password Reset Email Fallback: A Node.js Guide to Code and Link Evidence

Should a password reset email fallback use a code or a link?