Dead Letter Queue Stratejileri: Dayanıklı Olay-Güdümlü Sistemler için Production-Ready Kalıplar
DLQ stratejileri, monitoring ve recovery kalıpları için kapsamlı rehber. Circuit breaker, exponential backoff, ML-tabanlı recovery ve kaçınılması gereken anti-pattern'lar hakkında gerçek production deneyimleri.
Dead Letter Queue'lar dayanıklı olay-güdümlü sistemler inşa etmek için kritiktir. Sayısız production olayıyla uğraştıktan sonra, doğru DLQ stratejilerinin oyuncak sistemleri production-ready mimarilerden ayıran şey olduğunu öğrendim.
DLQ Nedir ve Neden İhtiyacınız Var#
DLQ, başarıyla işlenemeyen mesajlar için güvenlik ağınızdır. Doğru DLQ handling olmadan, başarısız mesajlar:
- Sonsuza kadar kaybolur (sessiz hatalar)
- Tüm kuyruğu bloke eder (poison pill problemi)
- Sonsuz retry döngüleri oluşturur (cascade hatalar)
DLQ'yu sisteminizin "acil servisi" olarak düşünün - hasta mesajların teşhis ve tedavi için gittiği yer.
DLQ Implementation Pattern'ları#
Pattern 1: Jitter ile Exponential Backoff#
En yaygın pattern, ama çoğu implementasyon yanlış yapıyor:
class DayanıklıMesajİşlemcisi {
async backoffIleİşle(mesaj: Message, maxRetry = 5) {
let retryCount = 0;
let sonHata;
while (retryCount < maxRetry) {
try {
return await this.işle(mesaj);
} catch (hata) {
sonHata = hata;
retryCount++;
// Thundering herd'i önlemek için jitter ekle
const temelGecikme = Math.pow(2, retryCount - 1) * 1000;
const jitter = Math.random() * 1000;
const gecikme = temelGecikme + jitter;
await this.bekle(gecikme);
// Retry bağlamıyla mesajı zenginleştir
mesaj.metadata = {
...mesaj.metadata,
retryCount,
sonHata: hata.message,
retryZamani: new Date().toISOString(),
backoffGecikme: gecikme
};
}
}
// Max retry aşıldı - tam bağlamla DLQ'ya gönder
await this.dlqyaGonder(mesaj, sonHata, retryCount);
}
}
Pattern 2: Circuit Breaker DLQ#
Downstream servis hataları için:
class CircuitBreakerDLQ {
private hatalar = new Map<string, { sayı: number, sonHata: Date }>();
private devreState: 'KAPALI' | 'AÇIK' | 'YARIM_AÇIK' = 'KAPALI';
async mesajIşle(mesaj: Message) {
const servisKey = this.servisKeyiÇıkar(mesaj);
if (this.devreAçıkMı(servisKey)) {
// Deneme bile yapma - direkt DLQ'ya circuit breaker sebebiyle
return this.dlqyaGonder(mesaj, new Error('Circuit breaker açık'), {
devreState: this.devreState,
hataCount: this.hatalar.get(servisKey)?.sayı || 0
});
}
try {
const sonuç = await this.timeoutIleİşle(mesaj, 30000);
this.başarıKaydet(servisKey);
return sonuç;
} catch (hata) {
this.hataKaydet(servisKey);
if (this.devreAçılmalıMı(servisKey)) {
this.devreAç(servisKey);
}
throw hata; // Normal retry mantığının halletmesine bırak
}
}
}
DLQ Monitoring: Temel Metriklerden Öte#
Çoğu team sadece DLQ derinliğini monitor eder. İzlemeniz gerekenler:
class DLQMonitoring {
private metrikler = {
// Temel metrikler
dlqDerinlik: new Gauge('dlq_depth'),
dlqOran: new Counter('dlq_messages_total'),
// Gelişmiş metrikler
dlqMesajYaş: new Histogram('dlq_message_age_seconds'),
hataKalıpları: new Counter('dlq_error_patterns', ['error_type', 'message_type']),
retryBaşarıOranı: new Gauge('dlq_retry_success_rate'),
// Business metrikler
gelirEtkisi: new Gauge('dlq_revenue_impact_dollars'),
müşteriEtkisi: new Counter('dlq_customer_impact', ['severity'])
};
}
DLQ Recovery Stratejileri#
Strateji 1: ML ile Otomatik Recovery#
class MLDLQRecovery {
async analizeEtveKurtar() {
const dlqMesajları = await this.dlqMesajlarınıGetir();
// Hata kalıplarına göre grupla
const hataGrupları = this.hataKalıplarınaGöreGrupla(dlqMesajları);
for (const [kalıp, mesajlar] of hataGrupları.entries()) {
// Bilinen bir düzeltmemiz var mı kontrol et
const düzeltme = await this.mlModel.düzeltmeTahminEt(kalıp);
if (düzeltme.confidence > 0.8) {
await this.otomatikDüzeltmeUygula(mesajlar, düzeltme);
} else {
await this.jiraTicketOluştur(kalıp, mesajlar, düzeltme);
}
}
}
}
Production DLQ Checklist#
- Uygun retention periyodları yapılandır (minimum 14 gün)
- DLQ derinlik alarmları kur (> 10 mesaj)
- DLQ yaş metriklerini monitor et (1 saatten eski mesajlar)
- Bilinen hata kalıpları için otomatik recovery uygula
- Manuel araştırma için runbook'lar oluştur
- DLQ mesajlarından business impact metriklerini takip et
- Team standuplarında düzenli DLQ review'ları
- Yüksek hata oranları sırasında DLQ davranışını load test et
Gerçek Dünya DLQ Savaş Hikayeleri#
50.000$ Payment DLQ Olayı#
DLQ'muz monitor edilmediği için payment'lar sessizce başarısız oluyordu. Mesajlar DLQ'ya gidiyordu ama hiç alarm kurulmamıştı. 50.000lık payment'ların DLQ'da sıkıştığını fark etmemiz 3 gün aldı.
Öğrenilen ders: Sadece ana kuyruk metriklerini değil, her zaman DLQ derinlik ve yaşını monitor et.
Sonuç#
İyi tasarlanmış bir DLQ stratejisi çoğu zaman küçük bir olay ile büyük bir kesinti arasındaki fark olur. Odaklan:
- Temel derinlik metriklerinin ötesinde kapsamlı monitoring
- Mesaj tipi ve hata kalıplarına dayalı akıllı routing
- Bilinen sorunlar için otomatik recovery
- Manuel müdahale için net runbook'lar
- Kalıpları geliştirmek için düzenli review'lar
Unutma: DLQ'n production güvenlik ağın. Ana işleme mantığına verdiğin özenin aynısını ona da ver.
İlgili Okuma: Olay-güdümlü sistem araçları ve kalıplarının daha geniş bir genel bakışı için olay-güdümlü mimari araçları kapsamlı rehberini görün.
Real-World DLQ War Stories#
Çeviri eklenecek.
Conclusion#
Çeviri eklenecek.
Yorumlar (0)
Sohbete katıl
Düşüncelerini paylaşmak ve toplulukla etkileşim kurmak için giriş yap
Henüz yorum yok
Bu yazı hakkında ilk düşüncelerini paylaşan sen ol!
Yorumlar (0)
Sohbete katıl
Düşüncelerini paylaşmak ve toplulukla etkileşim kurmak için giriş yap
Henüz yorum yok
Bu yazı hakkında ilk düşüncelerini paylaşan sen ol!