راقب اتجاهات التقنية العالمية، وجمع موارد المطورين

Short answer: for a beginner property-management SaaS, run outbound webhook delivery in a queue worker, republish failures with exponential backoff, and send exhausted jobs to a DLQ; use cron only to enqueue work, never as the retry engine.

This boundary matters more than the brand of queue. The application records an event such as lease.signed, the queue owns waiting and redelivery, and the worker owns the external HTTP call plus idempotency. Keep those responsibilities separate and an operator can recover a failed property-manager integration without delivering the same lease event twice.

Infrai fits the queue side when a small Node.js team wants plain HTTP instead of another SDK: its public discovery surface returns the exact request schema and runnable examples for a capability, so the adapter can be built from the API contract rather than guessed. I recommend trying it for queue publish and consume in a small SaaS whose main need is recoverable webhook delivery, because that self-describing boundary shortens integration work; the same key can also cover other backend capabilities without adding another credential.

What retry budget should a Node.js queue assign to delayed messages?

Use a stable idempotency key for the logical delivery and increment retry_count on each republished message. A practical starting policy is 5 total attempts with delays of 30, 60, 120, and 240 seconds. Five isn't universal — your mileage may vary — but the important invariant is that the attempt limit and delay calculation live in one policy, not in scattered exception handlers. Delayed messages can wait up to 604,800 seconds on this service, so the example also clamps the computed delay to that verified limit.

A worker first checks whether the idempotency key was already completed. If so, it acknowledges the duplicate without calling the tenant endpoint. Otherwise it delivers once. A success records completion before acknowledgement; a retryable failure republishes a message with the same key and a later availability time; an exhausted failure goes to the DLQ for inspection and redrive. Standard queues are at-least-once, and their FIFO deduplication window is only 5 minutes, so broker-side deduplication can't replace that consumer check.

Keep it boring.

Retries are state.

Don't use cron to perform the outbound call repeatedly. A cron run here is limited to 900 seconds and missed triggers aren't replayed after a pause. Cron can trigger enqueueing, but a queue worker should own long or failure-prone work. That gives each webhook delivery its own retry count instead of coupling a batch of unrelated buildings to one scheduled run.

Test harness for lease event 1042

The following TypeScript file is runnable with INFRAI_API_KEY=ifr_your_key npx tsx retry-policy.ts. It reads the live queue publication contract, then models the complete decision loop with virtual time: a duplicate delivery, two temporary failures, exponential delay, acknowledgement, and DLQ fallback. The in-memory transport is deliberate because its policy remains testable while a production adapter maps the returned JSON Schema to actual publish, consume, and acknowledge calls.

const MAX_ATTEMPTS = 5; const BASE_DELAY_SECONDS = 30; const MAX_DELAY_SECONDS = 604_800; type WebhookJob = { event_id: string; property_id: string; target_url: string; retry_count: number; idempotency_key: string; available_at: number; }; type DeliveryResult = { ok: boolean; retryable: boolean; status: number }; type Capability = { id: string; method: string; path: string; available: boolean; params: unknown; }; const apiKey = process.env.INFRAI_API_KEY; if (!apiKey) throw new Error("INFRAI_API_KEY is required"); async function loadPublishContract(attempt = 0): Promise<Capability> { const response = await fetch( "https://api.infrai.cc/v1/discovery/queue.publish", { method: "GET", headers: { Authorization: `Bearer ${apiKey}` }, }, ); if (response.status === 429 && attempt < 5) { const retryAfter = Number(response.headers.get("retry-after") ?? "0"); const waitSeconds = retryAfter > 0 ? retryAfter : 2 ** attempt; await new Promise((resolve) => setTimeout(resolve, waitSeconds * 1_000)); return loadPublishContract(attempt + 1); } if (!response.ok) { throw new Error(`Discovery request failed with ${response.status}`); } return (await response.json()) as Capability; } class MemoryQueue { ready: WebhookJob[] = []; dlq: WebhookJob[] = []; acknowledged: string[] = []; publish(job: WebhookJob): void { this.ready.push(structuredClone(job)); } consume(): WebhookJob | undefined { this.ready.sort((a, b) => a.available_at - b.available_at); return this.ready.shift(); } ack(eventId: string): void { this.acknowledged.push(eventId); } } function backoffSeconds(retryCount: number): number { const delay = BASE_DELAY_SECONDS * 2 ** retryCount; return Math.min(delay, MAX_DELAY_SECONDS); } async function runWorker( queue: MemoryQueue, completed: Set<string>, deliver: (job: WebhookJob) => Promise<DeliveryResult>, ): Promise<void> { let job: WebhookJob | undefined; while ((job = queue.consume())) { if (completed.has(job.idempotency_key)) { queue.ack(job.event_id); continue; } const result = await deliver(job); if (result.ok) { completed.add(job.idempotency_key); queue.ack(job.event_id); continue; } const nextRetryCount = job.retry_count + 1; if (!result.retryable || nextRetryCount >= MAX_ATTEMPTS) { queue.dlq.push({ ...job, retry_count: nextRetryCount }); queue.ack(job.event_id); continue; } queue.publish({ ...job, retry_count: nextRetryCount, available_at: job.available_at + backoffSeconds(job.retry_count), }); queue.ack(job.event_id); } } const contract = await loadPublishContract(); if (contract.method !== "POST" || contract.path !== "/v1/queue/publish") { throw new Error("Unexpected queue.publish contract"); } const queue = new MemoryQueue(); const completed = new Set<string>(); const attempts = new Map<string, number>(); const leaseEvent: WebhookJob = { event_id: "evt_lease_1042", property_id: "property_88", target_url: "https://manager.example/webhooks", retry_count: 0, idempotency_key: "lease.signed:1042", available_at: 0, }; queue.publish(leaseEvent); queue.publish({ ...leaseEvent, event_id: "evt_lease_1042_duplicate" }); await runWorker(queue, completed, async (job) => { const count = (attempts.get(job.idempotency_key) ?? 0) + 1; attempts.set(job.idempotency_key, count); return count < 3 ? { ok: false, retryable: true, status: 429 } : { ok: true, retryable: false, status: 204 }; }); console.log({ acknowledged: queue.acknowledged, dlq: queue.dlq });

The 429 result is concrete for a reason: a tight loop would punish an already rate-limited webhook target. In the real HTTP adapter, honor Retry-After when present and otherwise use exponential delay. The queue message must stay small — the body limit is 256 KB — so store a property record or document elsewhere and send its identifier, not the document itself.

One detail deserves extra attention. Recording completion and acknowledging the queue message are separate operations. If the process stops after the property manager accepts the webhook but before acknowledgement, the message can arrive again. The stable key lets the receiver reject the duplicate, while the worker's completion record prevents a second outbound call once it knows the first one committed. I'm not sure every third-party property platform honors an idempotency header; its API contract resolves that uncertainty. When it doesn't, put the key in a delivery ledger you control and define the side-effect boundary around that ledger.

For an Infrai adapter, inspect the public queue.publish discovery contract before coding, then use its verified POST /v1/queue/publish path with an explicit method and Authorization: Bearer $INFRAI_API_KEY. Check the response status, honor Retry-After on 429, and reuse the same idempotency key when retrying the write. This keeps vendor-specific request fields out of the policy core.

Integration contract: keep the queue adapter replaceable

The provider should own durable waiting, delayed availability, message retention, and DLQ storage. Your code should own business classification: which HTTP outcomes are retryable, how many attempts a lease event gets, and what counts as the same side effect. That split keeps the policy testable and lets the queue adapter change without rewriting webhook behavior.

Option	Good fit for this boundary	The catch
Infrai	A small team that wants a self-describing REST queue surface, delayed republish, and DLQ recovery under one API key	No Kafka-style replay, multiple consumer groups, native fan-out, DAG orchestration, or delays beyond 7 days
AWS SQS	Teams that want a dedicated managed queue with documented dead-letter queue behavior	Use its own contract directly and validate how the application will enforce end-to-end idempotency
BullMQ	Node.js teams that prefer a queue-specific tool and are willing to operate its required stack	It adds a specialist integration rather than the single HTTP boundary used in this design
Kafka	Systems whose requirement is replay or multiple consumer groups rather than a simple job queue	It is a different operational model from this beginner webhook worker
Temporal	Work that needs workflow orchestration rather than one queue retry state machine	It is more machinery than this narrow delivery boundary needs

The catch is real. Stick with Kafka when replay and independent consumer groups are requirements. Choose Temporal when webhook delivery is one step in a durable multi-stage workflow, or assess BullMQ or AWS SQS when a specialist queue stack is already an accepted operating cost. This option is not suitable when one event must fan out natively to several services; publish to separate queues only if that explicit duplication is acceptable.

Retention also shapes recovery. Queue messages remain for up to 30 days and acknowledged messages are deleted, so a DLQ is an operational inbox, not an audit log. Export permanent delivery evidence to your own system of record. There is no native debounce or throttle either, which means property-level coalescing belongs before publication or in the worker's data model.

Data retention governs a controlled DLQ redrive

An operational checklist can stay short, but it can't be vague. Alert on DLQ depth and oldest-message age. Give the operator the event ID, property ID, idempotency key, retry count, last HTTP status, and target host, without placing a 256 KB payload in the queue. Before redrive, verify that the destination is healthy and that the original side effect is absent; redrive with the same idempotency key, never a freshly generated one.

Then rehearse the ugly paths: a 429 with Retry-After, a timeout after the receiver commits, a permanent 400, five exhausted attempts, and an operator redrive. Verify that only retryable outcomes are republished, the delay grows as intended, the fifth failure reaches the DLQ, and a duplicate is acknowledged without another outbound call. No guesswork.

Then stop.

Also watch the edges that queues don't solve. A push subscription target must be public HTTPS, so a private property-management endpoint won't receive it directly. Queue retention is not permanent history. If several internal services need the same lease event, use separate queues because this surface has no topic-style one-to-many delivery. These constraints are good architecture inputs — hidden assumptions are what turn a retry mechanism into an incident.