Dead Letter Queue Stratejileri: Dayanıklı Olay-Güdümlü Sistemler için Production-Ready Kalıplar

Dead Letter Queue, bir tüketicinin retry bütçesini tükettikten sonra işleyemediği mesajları tutan kuyruktur. DLQ olmadan bir poison pill ya birincil kuyruğu baştan (head-of-line) tıkar ya da başarısız handler ile birlikte sessizce kaybolur; her iki sonuçta da hem event hem de bir şeylerin yanlış gittiğine dair operasyonel sinyal kaybedilir. DLQ, “işlenecek mesajlar” ile “insan ya da tool müdahalesi gerektiren mesajlar” arasındaki görev ayrımıdır ve yalnızca etrafındaki retry politikası, uyarı ve replay araçları birlikte tasarlandığında işe yarar.

Bu yazı, SQS, SNS ve EventBridge üzerinde production event-driven sistemleri için DLQ stratejilerini ele alır. Retry politikası sözleşmesini, DLQ uyarı ve replay mekanizmalarını, poison-pill desenlerini ve başarısız mesajlara erişim sağlamanın maliyet/görünürlük dengelerini kapsar.

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:

1. Sonsuza kadar kaybolur (sessiz hatalar)
2. Tüm kuyruğu bloke eder (poison pill problemi)
3. 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
    }
  }
}

Pattern 3: Content-Based DLQ Routing

Farklı mesaj tipleri farklı DLQ stratejileri gerektirir:

class SmartDLQRouter {
  private dlqStrategies = new Map([
    ['payment', { maxRetries: 10, alertLevel: 'CRITICAL' }],
    ['notification', { maxRetries: 3, alertLevel: 'WARNING' }],
    ['analytics', { maxRetries: 1, alertLevel: 'INFO' }],
  ]);

  async processMessage(message: Message) {
    const messageType = message.headers?.type || 'default';
    const strategy = this.dlqStrategies.get(messageType) || { maxRetries: 3, alertLevel: 'WARNING' };

    try {
      return await this.processWithStrategy(message, strategy);
    } catch (error) {
      // Mesaj tipi ve hataya göre uygun DLQ'ya yönlendir
      const dlqTopic = this.selectDLQTopic(messageType, error);
      await this.sendToSpecificDLQ(dlqTopic, message, error, strategy);
    }
  }

  private selectDLQTopic(messageType: string, error: Error): string {
    // Kritik mesajlar yüksek öncelikli DLQ'ya gider
    if (messageType === 'payment') {
      return 'payment-dlq-critical';
    }

    // Geçici hatalar retry DLQ'ya gider
    if (this.isTemporaryError(error)) {
      return 'retry-dlq';
    }

    // Kalıcı hatalar inceleme DLQ'sına gider
    return 'investigation-dlq';
  }
}

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);
      }
    }
  }
}

Strateji 2: Progressive Recovery

class ProgressiveDLQRecovery {
  async recoverInWaves(batchSize = 10) {
    let recovered = 0;
    let failed = 0;

    while (true) {
      const batch = await this.dlq.receiveMessages({ MaxMessages: batchSize });
      if (batch.length === 0) break;

      // Batch'leri aralarında exponential gecikmeyle işle
      const results = await this.processBatch(batch);

      recovered += results.successful;
      failed += results.failed;

      // Hata oranı yüksekse duraklat ve uyar
      const failureRate = failed / (recovered + failed);
      if (failureRate > 0.5) {
        await this.alertOncallTeam(`DLQ recovery failure rate: ${failureRate * 100}%`);
        await this.sleep(60000); // 1 dakika bekle
      }

      // Batch'ler arasında exponential backoff
      await this.sleep(Math.min(1000 * Math.pow(2, failed), 30000));
    }
  }
}

Cloud Provider DLQ Özellikleri

AWS SQS DLQ

# CloudFormation şablonu
Resources:
  MainQueue:
    Type: AWS::SQS::Queue
    Properties:
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt DLQ.Arn
        maxReceiveCount: 3
      MessageRetentionPeriod: 1209600  # 14 gün

  DLQ:
    Type: AWS::SQS::Queue
    Properties:
      MessageRetentionPeriod: 1209600  # 14 gün

  DLQAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: DLQ-HighDepth
      MetricName: ApproximateNumberOfMessagesVisible
      Namespace: AWS/SQS
      Dimensions:
        - Name: QueueName
          Value: !GetAtt DLQ.QueueName
      Statistic: Average
      Threshold: 10
      ComparisonOperator: GreaterThanThreshold

Azure Service Bus DLQ

// Otomatik DLQ yönetimi
var options = new ServiceBusProcessorOptions
{
    MaxConcurrentCalls = 10,
    MaxAutoLockRenewalDuration = TimeSpan.FromMinutes(10),
    // Mesajlar MaxDeliveryCount sonrası otomatik DLQ'ya gider (varsayılan: 10)
    SubQueue = SubQueue.None  // Ana kuyruk
};

// Recovery için DLQ'ya eriş
var dlqProcessor = client.CreateProcessor(
    queueName,
    new ServiceBusProcessorOptions { SubQueue = SubQueue.DeadLetter }
);

GCP Pub/Sub DLQ

# Terraform yapılandırması
resource "google_pubsub_subscription" "main" {
  name  = "main-subscription"
  topic = google_pubsub_topic.main.name

  dead_letter_policy {
    dead_letter_topic  = google_pubsub_topic.dlq.id
    max_delivery_attempts = 5
  }

  retry_policy {
    minimum_backoff = "10s"
    maximum_backoff = "600s"
  }
}

DLQ Kaçınılacak Anti-Pattern’lar

Infinite retry, DLQ’yu unutmak, tek DLQ tüm mesaj tipleri için, monitoring eksikliği, manuel recovery olmadan.

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

Yaygın DLQ Hata Kalıpları

Sessiz Payment Başarısızlığı

DLQ’lar izlenmediğinde payment’lar günlerce sessizce başarısız olabilir. Mesajlar DLQ’ya gider ama alarm kurulmamıştır; sorun fark edildiğinde binlerce dolarlık işlem sıkışmış olabilir. Çözüm: Sadece ana kuyruk metriklerini değil, her zaman DLQ derinlik ve yaşını monitor edin.

Thundering Herd

Downstream servis kesintisi sırasında, jitter olmadan eş zamanlı retry girişimleri toparlanmaya çalışan servisi aşırı yükler ve kesinti süresini uzatır. Çözüm: Retry girişimlerini yaymak için exponential backoff’a her zaman jitter ekleyin.

Poison Pill Bloklaması

Hatalı biçimlendirilmiş bir mesaj her denemede consumer servisi çökertebilir. Doğru DLQ routing olmadan yüksek trafik dönemlerinde sonraki tüm mesajları bloke eder. Çözüm: Circuit breaker’lar ve farklı hata tipleri için ayrı DLQ’lar uygulayın.

Sonuç

İyi tasarlanmış bir DLQ stratejisi çoğu zaman küçük bir olay ile büyük bir kesinti arasındaki fark olur. Odaklan:

1. Temel derinlik metriklerinin ötesinde kapsamlı monitoring
2. Mesaj tipi ve hata kalıplarına dayalı akıllı routing
3. Bilinen sorunlar için otomatik recovery
4. Manuel müdahale için net runbook’lar
5. 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.

Kaynaklar

• Amazon SQS’te dead-letter queue kullanımı - DLQ yapılandırması, redrive politikası ve maxReceiveCount için resmi SQS rehberi
• Amazon SQS konsolunda dead-letter queue yapılandırma - Kaynak kuyruğa DLQ eklemek için adım adım konsol rehberi
• Lambda’yı Amazon SQS ile kullanma - Lambda’nın SQS’i nasıl polling yaptığı, toplu işleme ve hataları DLQ’ya yönlendirme
• Amazon EventBridge nedir? - EventBridge event bus’ları, kurallar ve event hedefleri için dead-letter queue desteğine genel bakış
• Lambda fonksiyon ölçeklendirmeyi anlama - Thundering-herd retry senaryolarında eş zamanlılık ve ölçeklendirme davranışı
• Serverless Uygulamalar Lens - AWS Well-Architected - Olay güdümlü mimarilerde güvenilirlik ve hata işleme kalıpları
• Amazon SQS’te dead-letter queue saklama süresi ayarlama - Başarısız mesajların tanı ve tekrar oynatma için erişilebilir kalması amacıyla saklama süresi yapılandırması