BullMQ retry politikaları — dokümantasyonun söylemedikleri

BullMQ, Netorigo yığınındaki kuyruk sistemidir. Varsayılan retry politikası üstel bekleme süresiyle 3 denemedir. Mantıklı bir başlangıç gibi görünür — ancak pratikte her iş türü farklı bir strateji gerektirir. Aşağıdakiler, Netorigo backend ve Consulting OS iş çalıştırıcılarından production gözlemleridir.

E-posta gönderimi — agresif retry

E-posta nadiren başarısız olur; olduğunda da hata genellikle geçicidir (SMTP sunucusu ısınma süreci, hız sınırı). 5 deneme, 30 saniyelik bekleme, toplam ömür 10 dakika. O zamana kadar gitmediyse muhtemelen hiç gitmeyecektir — DLQ'ya düşer ve bir insan inceler. Nortinia ayda yaklaşık 80.000 e-posta gönderiyor; bunların yaklaşık 1.200'ü retry gerektiriyor ve 40'ı DLQ'ya düşüyor.

Ödeme webhook'u — bir kez, fazlası değil

Ödeme sağlayıcılarının webhook'ları (Stripe, Braintree, OTP SimplePay) idempotent olarak gelir. Onları yeniden denemek, aynı event'i iki kez işlemek — ve işlemi iki kez saymak demektir. 1 deneme, 0 retry. Hata olursa doğrudan DLQ'ya gider. Ödeme sağlayıcıları kendi taraflarında yeniden dener — bu onların işi, bizim değil.

Üçüncü taraflara giden webhook'lar

• 8 deneme, 1 saniyeden 2 saate kadar üstel bekleme
• Circuit breaker: hedef URL art arda 50 istekte 5xx dönerse kuyruk 10 dakika duraklatılır
• İş başına zaman aşımı: 30 saniye (yavaş bir müşteri backend'inin kuyruğu tıkamasına izin veremeyiz)
• DLQ yalnızca denemeler tükendiğinde VEYA 4xx (istemci tarafı hata) durumunda
• İmzalı payload — yeniden denemelerde aynı imza, aksi halde hedef reddeder

Kural

Repodaki her kuyruk bir retry politikası dokümanıyla birlikte gelir. Beş satırlık markdown: iş türü, gerekçesiyle retry stratejisi, DLQ koşulu, beklenen aylık DLQ oranı. Bir iş bu beş satıra sığmıyorsa yayına hazır değildir. Bu kalıp Netorigo yığınında 6 aydır çalışıyor ve o zamandan beri sıfır “sonsuz kuyruk döngüsü” olayı yaşadık.