The journal

Does Kafka have a dead-letter queue?

Short, practical answer with patterns: Kafka has no broker-level DLQ. Teams implement a DLQ as a topic, route failed records from consumers or frameworks, and replay safely later.

By Stack & Method editorial team · 2026-10-24

Diagram of Kafka topic flow with main topic lane, consumer group and side showing message envelopes metadata badges and offset commit arrows does kafka have a dead-letter queue

No. Apache Kafka brokers do not include a built-in, universal dead-letter queue. In practice, teams create a separate Kafka topic and route failed records there from their consumer logic or framework, then replay them later (https://www.confluent.io/learn/kafka-dead-letter-queue/).

What a Kafka DLQ actually is

A Kafka DLQ is just another topic that holds records a consumer could not process, so one bad record does not block a partition. The useful shape is the original payload plus enough error context to triage and safely replay later, such as source topic, partition and offset, failure reason, and attempt count (https://floriancourouge.com/en/blog/dead-letter-queues-kafka-patterns-production).

Minimalist 2D vector checklist diagram with four flat icons for publish commit alert and redrive on a pale background with blue strokes and yellow accents does kafka have a dead-letter queue

Where DLQ-like behavior exists in common stacks

Kafka Connect: Sink connectors can route failed records to a DLQ using errors.deadletterqueue.* settings; this mechanism applies to sink-side conversion/transform failures, not source connectors (https://factorhouse.io/resources/kafka/tools/kafka-dlq-tools/).
Spring Cloud Stream (Kafka binder): Can publish to a dead-letter topic and lets you customize topic naming and partitioning, but it intentionally does not prescribe how you handle or replay DLQ records, warning about potential replay loops and suggesting a parking-lot pattern for exhausted retries (https://docs.spring.io/spring-cloud-stream-binder-kafka/docs/current/reference/html/dlq.html).
Kafka Streams: Since Apache Kafka 4.2 (KIP-1034), exception handlers can send failed records to a DLQ topic; on older versions you build a custom handler to write to a quarantine topic (https://factorhouse.io/articles/dead-letter-queues-kafka/).

Operational pattern that works under load

A practical, low-drama sequence looks like this:

On failure, enrich the record with error metadata and publish it to a DLQ topic.
Commit the main consumer offset so the partition can advance and healthy records keep flowing.
Redrive later in a controlled way (small batches, backoff, and clear stop conditions). Spring Cloud Stream’s reference shows rerouting from a dead-letter topic and moving exhausted retries to a “parking lot” to avoid infinite loops (https://docs.spring.io/spring-cloud-stream-binder-kafka/docs/current/reference/html/dlq.html). For production patterns and pitfalls such as ordering and replay loops, see (https://factorhouse.io/articles/dead-letter-queues-kafka/).

Minimal editorial diagram of a record envelope with five field placeholders and icons for original key value headers error and trace id, does kafka have a dead-letter queue

Layout and retention choices

Per-consumer-group DLQs simplify ownership, triage and targeted replays; a shared “global” DLQ quickly becomes noisy and ambiguous (https://floriancourouge.com/en/blog/dead-letter-queues-kafka-patterns-production).
Partitions and keys: Preserve the original message key and ensure the DLQ has at least as many partitions as the source if you care about per-key ordering on replay (https://docs.spring.io/spring-cloud-stream-binder-kafka/docs/current/reference/html/dlq.html).
Retention: Set a retention that matches your investigation window; monitor both depth and the age of the oldest unprocessed DLQ record (https://factorhouse.io/articles/dead-letter-queues-kafka/).

Create and operate a Kafka dead-letter topic

Create a DLQ topic with partition count matching or exceeding the source topic
Publish failed records with context (source topic/partition/offset, error type/message, attempt count) in headers
After writing to the DLQ, commit the source offset to avoid reprocessing stalls
Set DLQ retention based on your SLA and storage budget
Alert on DLQ depth and on the age of the oldest unprocessed record
Document and test a redrive path that prevents loops and respects idempotency

Replay safely: avoid loops, duplicates and surprises

Avoid replay loops: Cap retries and route exhausted messages to a parking lot or DLQ; the Spring Cloud Stream docs explicitly warn that naive rerouting can loop forever (https://docs.spring.io/spring-cloud-stream-binder-kafka/docs/current/reference/html/dlq.html).
Targeted replay: Prefer replaying into a retry topic that only the affected consumer reads, rather than the main topic, to avoid re-invoking other consumers (https://factorhouse.io/articles/dead-letter-queues-kafka/).
Idempotency first: If your handler triggers side effects, build idempotency around a stable key so replays cannot double-charge or double-notify. See our primer on idempotency keys for practical patterns: Idempotency keys: safe retries without duplicate actions.
Retries with judgment: Use bounded retries with backoff for transient failures; our guidance on when to retry server errors gives practical thresholds: Should we retry on 500?

Common pitfalls to watch for

Assuming Kafka has a broker toggle for DLQ: It does not; you implement and operate it yourself (https://www.confluent.io/learn/kafka-dead-letter-queue/).
Confusing Connect coverage: DLQ routing in Connect covers sink-side conversion/transform errors; it is not a universal safety net for all task failures or for source connectors (https://factorhouse.io/resources/kafka/tools/kafka-dlq-tools/).
Ordering loss on replay: Changing keys or partition counts between source and DLQ breaks per-key ordering; keep keys and partitions aligned (https://docs.spring.io/spring-cloud-stream-binder-kafka/docs/current/reference/html/dlq.html).
Schema traps: If deserialization failed, writing the DLQ payload as raw bytes with error headers avoids a second failure on the DLQ itself (https://factorhouse.io/articles/dead-letter-queues-kafka/).

FAQ

Does Kafka have a broker-level DLQ I can enable?

No. You implement a DLQ as a topic and route failures from your consumer or framework (https://www.confluent.io/learn/kafka-dead-letter-queue/).

Can Kafka Connect send failed records to a DLQ automatically?

Yes for sink connectors via errors.deadletterqueue.*; this does not cover source connectors (https://factorhouse.io/resources/kafka/tools/kafka-dlq-tools/).

What about Kafka Streams?

From Apache Kafka 4.2, exception handlers can emit DLQ records directly; earlier versions require a custom handler (https://factorhouse.io/articles/dead-letter-queues-kafka/).