Ölü Mektup Kuyruğu (Dead Letter Queue - DLQ)

Sistem Analizi

MesajlaşmaPRODUCTION

Normal Davranış

Maksimum teslimat yeniden deneme (max-delivery retry) girişimleri aşıldıktan sonra hatalı (malformed) veya işlenemeyen (unprocessable) mesajları otomatik olarak keser, hata tanılama (diagnostic) başlıklarını (istisna yığın izlemeleri/exception stack traces, arıza zaman damgaları, deneme sayıları) ekler ve ana işleme kuyruğunun (queue) engellenmeden çalışmaya devam etmesini sağlamak için yükleri güvenli bir şekilde park eder.

Çöküş Davranışı

Kuyruk depolama alanı (disk storage) tamamen dolana kadar zehirli hap (poison-pill) mesajlarını izleme veya uyarı olmadan aylarca sessizce biriktirir veya bir mühendis tüm düzeltilmemiş DLQ'yu körü körüne birincil kuyruğa (primary queue) yeniden oynattığında (replay) patlayıcı bir tüketici (consumer) kesintisini tetikler.

İş Sonuçları

Bir Ölü Mektup Kuyruğunu (Dead Letter Queue - DLQ) izleyememek veya işlememek, düşen işlemlerin boşlukta kalıcı olarak kaybolması anlamına gelir. Bu, yerine getirilmeyen müşteri siparişlerine, kaçırılan finansal defter (ledger) kayıtlarına ve sessiz veri bozulmasına neden olur. DLQ görünürlüğü (visibility) olmadan, sistem iş mantığının uç durumlarını (edge-case) sistematik olarak işleyemezken sahte bir operasyonel sağlık (operational health) raporlar.

Görsel Tezahür

"Belirsiz bir gösterge panelinde hızla artan bir mesaj sayısı (message count), 'eksik siparişler' ('missing orders') hakkındaki müşteri destek biletleri katlanarak çoğalırken."

Satirical Behavior

"The digital rug under which enterprise messaging systems sweep all their failures, hoping no one ever asks why 15,000 checkout events are just sitting there."

Bilinen İsimler

DLQFailed Messages

Teknik Terminoloji

Message replayMax retriesPoison pill

Hata Göstergeleri

Queue overflowUnprocessable messageDropped events

Sistem Mimarisi

Click or hover to interact

Kullanan Karakterler

glitch

FAQ

Normalde nasıl davranır?

Nasıl çöker?

İş sonuçları nelerdir?

What is a Dead Letter Queue (DLQ) and what problem does it solve in asynchronous architectures?

In asynchronous, message-driven systems (like Apache Kafka, AWS SQS, or RabbitMQ), a 'poison pill'—a message with invalid JSON, missing database foreign keys, or unexpected data types—can cause consumer services to repeatedly crash. Without a Dead Letter Queue, the consumer either crashes indefinitely (halting all message processing) or drops the message (causing irreversible data loss). A DLQ solves this by routing failing messages to a safe side-queue after a predefined number of retry attempts, preserving normal pipeline throughput while retaining failed events for inspection.

What is a 'poison message replay storm' and how should DLQ monitoring and redrive workflows be configured?

A poison replay storm occurs when an operator blindly redrives all failed DLQ messages back into the main queue without first deploying a bug fix for the underlying consumer error or data schema mismatch; the consumers instantly fail again, exhausting retries and refilling the DLQ in an infinite crash loop. Prevent this by setting up automated alerts on DLQ arrival velocity and queue depth, inspecting and testing sample payloads in staging environments before redriving, and using automated redrive tools with rate limiting and dry-run validation.

Sistemi keşfet

Incidentpedia'da devam et→Olay Dizinini oku→Stack'leri incele→Konuları keşfet→Bölümleri izle→Ajanlar→

AI özeti

Dead Letter Queue (DLQ) is a MESSAGING system in TinyCTO.tv. Automatically intercepts malformed or unprocessable messages after max-delivery retry attempts are breached, appends error diagnostic headers (exception stack traces, failure timestamps, attempt counts), and securely parks payloads to allow the main processing queue to continue operating without blocking.