Backend interview prep

Start

Kafka Dead Letter Queue (DLQ) Interview Questions and Answers

Learn Kafka Dead Letter Queue (DLQ) with interview questions, Mermaid diagrams, Spring Kafka examples, retry topics, DeadLetterPublishingRecoverer, and enterprise production best practices.

Kafka Dead Letter Queue (DLQ) - Interview Questions & Answers

Apache Kafka is designed for high-throughput, distributed event streaming, but message processing failures are inevitable in production systems.

Examples include:

  • Invalid Event Payload
  • Database Failure
  • External API Timeout
  • Serialization Errors
  • Business Validation Failures
  • Downstream Service Unavailability

A Dead Letter Queue (DLQ) ensures that permanently failing events are isolated instead of blocking consumers.

Kafka DLQs are commonly implemented using:

  • Spring Kafka
  • DeadLetterPublishingRecoverer
  • Retry Topics
  • RetryableTopic
  • Kafka Streams
  • Kafka Connect

Kafka DLQ Architecture

flowchart LR

Producer --> KafkaTopic["Kafka Topic"]

KafkaTopic["Kafka Topic"] --> Consumer

Consumer -- Success --> Database

Consumer -- Failure --> RetryTopic["Retry Topic"]

RetryTopic["Retry Topic"] --> Consumer

Consumer -- Retry Limit Exceeded --> DlqTopic["DLQ Topic"]

DlqTopic["DLQ Topic"] --> ReplayService["Replay Service"]

Q1. What is a Kafka Dead Letter Queue (DLQ)?

Answer

A Kafka DLQ is a special Kafka topic that stores messages that cannot be successfully processed after configured retry attempts.

Instead of continuously retrying failed events, Kafka publishes them to a dedicated DLQ topic.

Benefits include:

  • Prevents consumer blocking
  • Preserves failed events
  • Supports troubleshooting
  • Enables replay

DLQ Flow

flowchart TD

Producer --> MainTopic["Main Topic"]

MainTopic["Main Topic"] --> Consumer

Consumer --> Retry

Retry --> DlqTopic["DLQ Topic"]

Q2. Why do Kafka applications need a DLQ?

Answer

Kafka guarantees message delivery, but it cannot automatically resolve application errors.

Common failures include:

  • Invalid JSON
  • Schema mismatch
  • Database unavailable
  • Business rule violations
  • Network failures
  • Serialization exceptions

Without a DLQ:

  • Consumer repeatedly fails
  • Partition processing stops
  • Consumer lag increases

Without DLQ

flowchart LR

KafkaTopic["Kafka Topic"] --> Consumer

Consumer --> Failure

Failure --> RetryForever["Retry Forever"]

With DLQ

flowchart LR

KafkaTopic["Kafka Topic"] --> Consumer

Consumer --> Retry

Retry --> DlqTopic["DLQ Topic"]

Q3. How does a Kafka DLQ work?

Answer

Typical workflow:

  1. Producer publishes an event.
  2. Consumer processes it.
  3. Processing fails.
  4. Retry policy executes.
  5. Retry limit is exceeded.
  6. Event is published to the DLQ topic.
  7. Operations team investigates or replays the event.

Kafka DLQ Lifecycle

sequenceDiagram
participant Producer
participant Kafka
participant Consumer
participant Retry
participant DLQ
Producer->>Kafka: Publish Event
Kafka->>Consumer: Consume
Consumer-->>Retry: Failure
Retry-->>Consumer: Retry
Consumer-->>DLQ: Publish Failed Event

Q4. What is DeadLetterPublishingRecoverer?

Answer

DeadLetterPublishingRecoverer is a Spring Kafka component that publishes failed records to a Dead Letter Topic after retries are exhausted.

Responsibilities:

  • Sends failed events to a DLQ topic
  • Preserves message metadata
  • Supports custom routing
  • Integrates with retry handlers

Spring Kafka Flow

flowchart TD

Consumer --> RetryHandler["Retry Handler"]

RetryHandler["Retry Handler"] --> DeadLetterPublishingRecoverer

DeadLetterPublishingRecoverer --> DlqTopic["DLQ Topic"]

Interview Tip

DeadLetterPublishingRecoverer is one of the most frequently discussed Spring Kafka classes in interviews.

Q5. What are Retry Topics in Kafka?

Answer

Retry Topics delay message processing before moving events to the DLQ.

Typical flow:

orders

↓

orders-retry-1

↓

orders-retry-2

↓

orders-retry-3

↓

orders-dlt

Benefits:

  • Controlled retries
  • Exponential backoff
  • Reduced pressure on downstream systems

Retry Topics

flowchart LR

OrdersTopic["Orders Topic"] --> Retry1["Retry 1"]

Retry1["Retry 1"] --> Retry2["Retry 2"]

Retry2["Retry 2"] --> Retry3["Retry 3"]

Retry3["Retry 3"] --> DlqTopic["DLQ Topic"]

Q6. How does Spring Boot implement Kafka DLQ?

Answer

Spring Boot integrates with Kafka using Spring Kafka.

Common components include:

  • @KafkaListener
  • DefaultErrorHandler
  • DeadLetterPublishingRecoverer
  • RetryableTopic
  • KafkaTemplate

Spring Boot Architecture

flowchart TD

SpringBoot["Spring Boot"] --> KafkaListener["Kafka Listener"]

KafkaListener["Kafka Listener"] --> RetryHandler["Retry Handler"]

RetryHandler["Retry Handler"] --> DeadLetterPublishingRecoverer

DeadLetterPublishingRecoverer --> KafkaDlq["Kafka DLQ"]

Benefits

  • Automatic retries
  • Automatic DLQ publishing
  • Configurable retry strategy

Q7. What information should be stored in a Kafka DLQ message?

Answer

A DLQ record should contain enough context for troubleshooting and replay.

Recommended metadata:

  • Original Topic
  • Partition
  • Offset
  • Timestamp
  • Exception Message
  • Stack Trace (optional)
  • Retry Count
  • Original Payload
  • Consumer Group

DLQ Metadata

mindmap
  root((DLQ Message))
    Topic
    Partition
    Offset
    Timestamp
    Exception
    Retry Count
    Payload
    Consumer Group

Q8. What are common Kafka DLQ implementation mistakes?

Answer

Common mistakes include:

  • Infinite retries
  • No retry topics
  • Ignoring poison messages
  • Missing monitoring
  • Losing original metadata
  • No replay mechanism
  • Replaying without idempotency

Wrong Design

Consumer

↓

Failure

↓

Retry Forever ❌

Correct Design

Consumer

↓

Retry Topics

↓

DLQ Topic

↓

Replay Service ✅

Q9. How should Kafka DLQs be monitored?

Answer

Monitor the following metrics:

  • DLQ Topic Size
  • Retry Rate
  • Consumer Lag
  • Replay Success Rate
  • Processing Latency
  • Exception Count
  • Throughput

Monitoring

flowchart TD

Kafka --> Micrometer

Micrometer --> Prometheus

Prometheus --> Grafana

Grafana --> Alerts

Best Practice

Trigger alerts before DLQ growth becomes critical.

Q10. What are the enterprise best practices for Kafka DLQ?

Answer

Follow these recommendations:

  • Retry before sending to the DLQ.
  • Use Retry Topics with exponential backoff.
  • Publish failed events using DeadLetterPublishingRecoverer.
  • Preserve original message metadata.
  • Build replay tools.
  • Make consumers idempotent.
  • Monitor DLQ growth continuously.
  • Audit replay operations.
  • Separate retryable and permanent failures.
  • Test replay scenarios regularly.

Enterprise Kafka Architecture

flowchart TD

Producer --> OrdersTopic["Orders Topic"]

OrdersTopic["Orders Topic"] --> Consumer

Consumer --> RetryTopic["Retry Topic"]

RetryTopic["Retry Topic"] --> Consumer

Consumer --> Orders-DLT

Orders-DLT --> ReplayService["Replay Service"]

ReplayService["Replay Service"] --> OrdersTopic["Orders Topic"]

Orders-DLT --> MonitoringDashboard["Monitoring Dashboard"]

Kafka Event Lifecycle

flowchart LR

Producer --> Topic
Topic --> Consumer
Consumer --> RetryTopics["Retry Topics"]
RetryTopics["Retry Topics"] --> DlqTopic["DLQ Topic"]
DlqTopic["DLQ Topic"] --> Replay
Replay --> Topic

Kafka DLQ Overview

mindmap
  root((Kafka DLQ))
    Retry Topics
    DeadLetterPublishingRecoverer
    DefaultErrorHandler
    Replay
    Monitoring
    Idempotency
    Metadata
    Alerts

Real-World Banking Example

A payment service publishes transaction events.

Customer Makes Payment

↓

payments Topic

↓

Payment Consumer

↓

Database Timeout

↓

payments-retry-1

↓

payments-retry-2

↓

payments-retry-3

↓

payments-dlt

↓

Operations Team Reviews

↓

Database Restored

↓

Replay Service

↓

Payment Processed Successfully

No transaction is lost, and normal consumers continue processing new events.

Senior Interview Tip

A Kafka DLQ is not simply a failed-events topic—it is part of a resilient event processing architecture.

A production-ready Kafka platform typically includes:

  • Apache Kafka Cluster
  • Spring Boot
  • Spring Kafka
  • Retry Topics
  • RetryableTopic
  • DefaultErrorHandler
  • DeadLetterPublishingRecoverer
  • KafkaTemplate
  • Idempotent Consumers
  • Prometheus & Grafana
  • Replay Services
  • Audit Logging
  • Schema Registry
  • Zero Message Loss Strategy

Remember:

  • Retry Topics handle transient failures.
  • DLQ Topics isolate repeated or permanent failures.
  • Replay Services recover failed business events safely after the root cause is resolved.

Quick Revision

  • Kafka DLQs store events that cannot be processed after retries.
  • Use Retry Topics before publishing to the DLQ.
  • Spring Kafka provides DeadLetterPublishingRecoverer for automatic DLQ publishing.
  • Preserve original topic, partition, offset, and exception details.
  • Build replay tools for operational recovery.
  • Monitor DLQ size, consumer lag, and retry rates.
  • Implement idempotent consumers for safe replay.
  • Separate retryable and permanent failures.
  • Test DLQ and replay scenarios regularly.
  • Combine retries, DLQs, monitoring, replay, and idempotency for enterprise-grade Kafka event processing.