BullMQ retry policies — amit a dokumentáció nem mond el

A BullMQ a Netorigo stack queue megoldása. Default retry policy-ja 3 attempt és exponenciális backoff. Ez tűnik okos alapnak — de a valóságban minden feladat más stratégiát igényel. Az alábbiak éles tapasztalatok a Netorigo backend és a Consulting OS job futtatásaiból.

Email küldés — agresszív retry

Az email küldés ritkán hibázik, és ha igen, a hiba általában átmeneti (SMTP szerver tréning, rate limit). 5 attempt, 30 másodperces backoff, max 10 perc teljes lifetime. Ha eddig nem ment át, valószínűleg sose fog — DLQ-ba megy és ember átnézi. A Nortinia havonta kb. 80 000 emailt küld, ebből 1 200 retry-t igényel, 40 DLQ-ba esik.

Fizetési webhook — egyszer, nem többször

A payment provider webhook-ja (Stripe, Braintree, OTP SimplePay) idempotent módon érkezik. Ha retry-oljuk, ugyanazt az eseményt kétszer dolgozzuk fel — és kétszer számoljuk a tranzakciót. 1 attempt, 0 retry. Ha elbukik, azonnal DLQ-ba megy. A payment providerek maguk retry-oznak a saját oldalukon — ez az ő felelősségük, nem a miénk.

Webhook küldés harmadik félnek

• 8 attempt, exponenciális backoff 1s-től 2 óráig
• Circuit breaker: ha a target URL 50 egymást követő request-ben 5xx, a queue 10 percre szünetel
• Timeout jobonként: 30 másodperc (nem hagyhatjuk, hogy egy lassú ügyfél backend elfojtsa a queue-t)
• DLQ-ba csak akkor, ha minden retry elfogyott VAGY 4xx (kliens oldali hiba)
• Signed payload — még a retry-okban is ugyanaz a signature, különben a target nem fogadja el

A szabály

Minden queue-hoz tartozik egy retry policy dokumentum a repo-ban. 5 sor markdown: feladat típus, retry stratégia indoklással, DLQ feltétel, várható DLQ ráta havonta. Ha egy job nem fér bele ebbe az öt sorba, nem vagyunk készek a deploy-ra. Ez a minta 6 hónapja fut a Netorigo stack-en, és azóta egyetlen "queue infinite loop" incidens sem volt.