Kuyrukta poison pill (zehirli mesaj) ve Dead Letter Queue'yu nasıl yönetirim?

Kısa cevap: Her seferinde patlayan ve sonsuza dek otomatik retry edilen bir iş, kuyruğu kilitleyip worker’ı çökertir — buna poison pill (zehirli mesaj) denir. Çözüm retry’ı sınırlamak ve hatalı işi yeniden kuyruğa atmak yerine bir DLQ’ya düşürmek.

Senin yaşadığın şey klasik: iş sürekli aynı yerde patlıyor, Laravel “tekrar deneyeyim” diyor, tekrar patlıyor, kuyruk ilerleyemiyor. Döngüyü kırman gerekiyor.

1. Retry’ı sınırla. İşin üstüne tries (ya da maxExceptions) ve bir backoff koy. Böylece iş 3-5 kez denenir, her seferinde sonsuza dek değil. Belirlenen sınıra ulaşınca Laravel onu yeniden kuyruğa atmayı bırakır.
2. failed_jobs senin yerleşik DLQ’n. Sınır dolunca Laravel işi otomatik failed_jobs tablosuna taşır — ekstra bir altyapı kurmana gerek yok, Dead Letter Queue zaten budur. İşin üstüne failed() metodu tanımlayıp temizlik/telafi mantığını oraya koy.
3. Alert kur. Bir JobFailed listener’ı yaz; iş failed_jobs’a düştüğü an Slack/Sentry’ye bildirim göndersin. “Sessizce başarısız olan iş” en kötü senaryodur; yöneticiler anında haberdar olmalı. İncelemeden sonra queue:retry ile düzeltilen işi replay edersin.
4. Fatal Error’ı ayrı ele al. Exception değil, worker’ı komple öldüren Fatal Error için Laravel’in normal retry’ı işlemez. Supervisor worker’ı yeniden başlatır ama aynı iş tekrar çekilirse döngü kapanmaz. Bunun için “bu job id’yi N kez gördüm” sayacı (Redis’te) tutup eşiği aşınca işi zorla failed_jobs’a at.
5. Kuyrukları riske göre ayır, işleri idempotent yap. Riskli iş tiplerini ayrı bir kuyrukta çalıştır ki tek bir kötü iş tüm diğerlerini aç bırakmasın. Ayrıca işleri idempotent yaz; retry güvenli olsun, iki kez çalışsa da yan etki birikmesin.

Sonuç: Sınırlı retry + failed_jobs DLQ + alert + queue:retry ile replay. Hiçbir işin sınırsız retry edilmesine izin verme; sınırsız retry, tek bir zehirli mesajı tüm sistemi durduran bir silaha çevirir.