Webhook Failure Recovery 2026: B2B डिजिटल गुड्स API के लिए patterns
B2B digital-goods integrations में webhook delivery एक critical path है: missed order.delivered event का मतलब है कि gift-card code customer तक नहीं पहुँचा और support tickets से भर गया। यह article उन production patterns को cover करता है जो top FoxReload partners 99.95%+ uptime पर run करते हैं।
1. Jitter के साथ exponential backoff — math
हर 30 सेकंड का naive retry incident के दौरान आपके receiver को मार देगा (thundering herd)। सही formula:
function nextRetryDelay(attempt: number): number {
const base = 30_000; // 30s
const cap = 6 * 60 * 60 * 1000; // 6h
const exp = Math.min(base * Math.pow(2, attempt), cap);
const jitter = Math.random() * exp * 0.3; // ±30%
return exp + jitter;
}
FoxReload exactly यही algorithm use करता है: attempts 1–8, 30s → 24h window में spread। 6-hour cap एक single webhook को worker पर हमेशा के लिए कब्जा नहीं करने देता, और ±30% jitter retry spikes को fleet में smooth करता है।
2. Dead-letter queue (DLQ)
8 failed attempts के बाद event DLQ में जाना चाहिए, lost नहीं होना चाहिए। Production pattern — manual replay के साथ dedicated queue:
// Express + BullMQ
app.post('/webhook/foxreload', async (req, res) => {
const sig = req.header('X-Foxreload-Signature');
if (!verifyHmac(req.rawBody, sig, process.env.WEBHOOK_SECRET)) {
return res.sendStatus(401);
}
const eventId = req.header('X-Foxreload-Event-Id');
const fresh = await redis.set(`evt:${eventId}`, '1', 'EX', 86400, 'NX');
if (!fresh) return res.sendStatus(200); // already processed
await queue.add('process-event', req.body, {
attempts: 8,
backoff: { type: 'exponential', delay: 30000 },
removeOnFail: false, // DLQ inspection के लिए रखें
});
res.sendStatus(200);
});
DLQ events on-call engineer review करता है: या तो POST /v1/webhooks/{id}/replay से replay करें, या admin में manually close करें।
3. Idempotency keys — non-negotiable
Webhook delivery at-least-once है, exactly-once नहीं। बिना idempotency के एक order.delivered event inventory दो बार decrement कर सकता है। X-Foxreload-Event-Id को natural idempotency key के तौर पर use करें:
| Storage | Latency | TTL | Cost / 1M events |
|---|---|---|---|
| Redis SETNX | <2ms | 24h | $0.40 |
| Postgres UNIQUE index | 5–8ms | forever | $0.10 |
| DynamoDB ConditionExpression | 8–12ms | 24h | $1.25 |
ज़्यादातर partners के लिए Redis SETNX optimal है: सस्ता, fast, और TTL FoxReload retry window (24h) cover करता है।
4. >1% loss पर alerting
जो metric monitor करना ज़रूरी है: rolling 5-minute webhook delivery success rate। अगर यह 99% से नीचे गिरे, यह incident है। Prometheus rule:
- alert: WebhookDeliveryDegraded
expr: |
(sum(rate(webhook_received_total[5m]))
- sum(rate(webhook_failed_total[5m])))
/ sum(rate(webhook_received_total[5m])) < 0.99
for: 2m
labels: { severity: page }
Alert PagerDuty/Opsgenie में route होता है, on-call DLQ और receiver logs देखता है। 80% cases में root cause recent receiver deploy regression होती है — rollback 5 minutes में resolve कर देता है।
CTA
Full FoxReload webhook documentation, replay endpoints और Prometheus metrics onboarding के बाद available हैं — API access request करें।