Implementing Dead Letter Topics (DLT)
Configure dead-letter topics to capture and store messages that repeatedly fail processing, enabling later analysis and reprocessing.
Implementing Dead Letter Topics (DLT) is a free Advanced Spring Boot 4: Event-Driven Architecture (Kafka) lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Advanced Spring Boot 4: Event-Driven Architecture (Kafka) learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Dead Letter Topics?
In event-driven systems, consumers sometimes fail to process messages due to transient errors (e.g., database unavailable) or permanent issues (e.g., malformed data).
- What happens to these failed messages?
- Do we retry them indefinitely, blocking the queue?
- Or do we discard them, potentially losing critical data?
This is where Dead Letter Topics (DLTs) come in!
What is a Dead Letter Topic?
A Dead Letter Topic (DLT) is a dedicated Kafka topic where messages that repeatedly fail processing are sent.
- It acts as a 'quarantine' for problematic messages.
- Instead of blocking the main consumer or losing data, messages are moved to the DLT.
- This allows the main consumer to continue processing new messages.
Messages in a DLT can then be inspected, manually corrected, or reprocessed later.
Spring Kafka's DLT Support
Spring for Apache Kafka provides excellent support for DLTs through its error handling mechanisms.
The key component is the DefaultErrorHandler, which can be configured to publish failed messages to a DLT after a certain number of retries.
It uses a DeadLetterPublishingRecoverer internally to perform the actual publishing.
Basic DLT Configuration
To enable DLT for a @KafkaListener, you can configure the DefaultErrorHandler with a DeadLetterPublishingRecoverer. This example sets up a simple DLT after 3 delivery attempts.
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.kafka.listener.DeadLetterPublishingRecoverer;
import org.springframework.kafka.listener.DefaultErrorHandler;
import org.springframework.util.backoff.FixedBackOff;
@SpringBootApplication
public class DltApplication {
public static void main(String[] args) {
SpringApplication.run(DltApplication.class, args);
}
@Bean
public DefaultErrorHandler errorHandler(KafkaTemplate<?, ?> kafkaTemplate) {
// Publish to DLT after 3 delivery attempts
// FixedBackOff(interval, maxAttempts) -> interval is ignored for DLT after retries
return new DefaultErrorHandler(new DeadLetterPublishingRecoverer(kafkaTemplate),
new FixedBackOff(0L, 2L)); // 0L interval, 2 retries = 3 attempts total
}
@KafkaListener(topics = "my-main-topic", groupId = "my-group", errorHandler = "errorHandler")
public void listen(String message) {
System.out.println("Received: " + message);
if (message.contains("fail")) {
throw new RuntimeException("Simulating processing failure!");
}
}
// To send messages for testing (not part of DLT config itself)
// @Autowired
// private KafkaTemplate<String, String> template;
// @EventListener(ApplicationReadyEvent.class)
// public void sendMessage() {
// template.send("my-main-topic", "Hello");
// template.send("my-main-topic", "This will fail");
// }
}Understanding DLT Topic Names
By default, Spring Kafka names the DLT topic by appending .DLT to the original topic name. For example, if your main topic is my-main-topic, the DLT will be my-main-topic.DLT.
- You can customize this behavior.
- The
DeadLetterPublishingRecovererconstructor can take aBiFunctionto determine the DLT topic and partition. - This allows for more flexible naming conventions or routing failed messages to different DLTs based on criteria.
Message Headers in DLT
When a message is sent to a DLT, Spring Kafka adds several useful headers to it. These headers provide context about why the message ended up in the DLT:
dlt_exception-fqcn: Fully qualified class name of the exception.dlt_exception-message: Message from the exception.dlt_exception-stacktrace: Full stack trace.dlt_original-topic: The topic the message came from.dlt_original-partition: The original partition.dlt_original-offset: The original offset.
These headers are invaluable for debugging and reprocessing.
Customizing DLT Publishing
You can provide a custom DeadLetterPublishingRecoverer to gain fine-grained control over how messages are published to the DLT. This allows you to modify headers, filter messages, or even prevent certain messages from going to the DLT.
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.kafka.listener.DeadLetterPublishingRecoverer;
import org.springframework.kafka.listener.DefaultErrorHandler;
import org.springframework.kafka.support.KafkaHeaders;
import org.springframework.messaging.Message;
import org.springframework.messaging.support.MessageBuilder;
import org.springframework.util.backoff.FixedBackOff;
@SpringBootApplication
public class CustomDltApplication {
public static void main(String[] args) {
SpringApplication.run(CustomDltApplication.class, args);
}
@Bean
public DefaultErrorHandler customErrorHandler(KafkaTemplate<Object, Object> kafkaTemplate) {
DeadLetterPublishingRecoverer customRecoverer = new DeadLetterPublishingRecoverer(kafkaTemplate,
(record, exception) -> { // Custom DLT topic/partition resolver
System.out.println("Sending to DLT: " + record.topic() + ".custom.dlt");
return new DeadLetterPublishingRecoverer.HeaderNames(record.topic() + ".custom.dlt", null);
});
return new DefaultErrorHandler(customRecoverer, new FixedBackOff(0L, 1L)); // 1 retry = 2 attempts total
}
@KafkaListener(topics = "another-topic", groupId = "my-custom-group", errorHandler = "customErrorHandler")
public void listenWithCustomDlt(String message) {
System.out.println("Received (custom DLT): " + message);
if (message.contains("fail")) {
throw new RuntimeException("Simulating custom DLT failure!");
}
}
}Consuming DLT Messages
Once messages are in a DLT, you'll need another consumer to process them. This DLT consumer can be designed to:
- Log the error and notify administrators.
- Store the message in a database for manual review.
- Attempt to reprocess the message after a delay or transformation.
It's just another @KafkaListener, but configured to listen to the DLT topic.
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.kafka.annotation.KafkaListener;
import org.springframework.kafka.core.KafkaTemplate;
import org.springframework.kafka.listener.DeadLetterPublishingRecoverer;
import org.springframework.kafka.listener.DefaultErrorHandler;
import org.springframework.messaging.handler.annotation.Header;
import org.springframework.kafka.support.KafkaHeaders;
import org.springframework.util.backoff.FixedBackOff;
@SpringBootApplication
public class DltConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(DltConsumerApplication.class, args);
}
@Bean
public DefaultErrorHandler errorHandler(KafkaTemplate<?, ?> kafkaTemplate) {
return new DefaultErrorHandler(new DeadLetterPublishingRecoverer(kafkaTemplate),
new FixedBackOff(0L, 2L));
}
@KafkaListener(topics = "my-main-topic", groupId = "my-group", errorHandler = "errorHandler")
public void listenMain(String message) {
System.out.println("Main Listener Received: " + message);
if (message.contains("fail")) {
throw new RuntimeException("Main processing failure!");
}
}
@KafkaListener(topics = "my-main-topic.DLT", groupId = "dlt-group")
public void listenDlt(String message,
@Header(KafkaHeaders.RECEIVED_TOPIC) String receivedTopic,
@Header(KafkaHeaders.ORIGINAL_OFFSET) Long originalOffset,
@Header(KafkaHeaders.EXCEPTION_MESSAGE) String exceptionMessage) {
System.out.println("DLT Listener Received: " + message);
System.out.println(" From Topic: " + receivedTopic);
System.out.println(" Original Offset: " + originalOffset);
System.out.println(" Exception: " + exceptionMessage);
// Here you would implement logic to store, alert, or reprocess
}
}DLT Best Practices
To effectively use DLTs, consider these best practices:
- Monitor DLTs: Set up alerts for messages appearing in DLTs, as they indicate persistent issues.
- Process DLTs: Don't let DLTs grow indefinitely. Have a plan to consume and handle these messages.
- Idempotency: Ensure your DLT reprocessing logic is idempotent to avoid duplicate processing issues.
- Separate Concerns: Keep DLT consumers separate from your main application logic for clearer responsibilities.
- Schema Evolution: Be mindful of schema changes when reprocessing old DLT messages.
DLT Quick Check
Which of the following is the primary benefit of using a Dead Letter Topic (DLT) in a Kafka consumer application?
Recap: DLT for Robustness
You've learned how Dead Letter Topics are a crucial component for building robust and resilient Kafka consumer applications.
- DLTs quarantine messages that fail repeated processing.
- Spring Kafka's
DefaultErrorHandlerandDeadLetterPublishingRecoverersimplify DLT integration. - Messages sent to DLTs include useful headers for debugging.
- DLTs require a separate consumer to handle the failed messages.
By implementing DLTs, you ensure your consumers can gracefully handle errors, prevent data loss, and maintain steady message flow.
Frequently asked questions
Is the “Implementing Dead Letter Topics (DLT)” lesson free?
Yes — the full text of “Implementing Dead Letter Topics (DLT)” is free to read here on the web, and the Advanced Spring Boot 4: Event-Driven Architecture (Kafka) course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Advanced Spring Boot 4: Event-Driven Architecture (Kafka) course, upgrade to CoddyKit PRO.
What will I learn in “Implementing Dead Letter Topics (DLT)”?
Configure dead-letter topics to capture and store messages that repeatedly fail processing, enabling later analysis and reprocessing. You practise Advanced Spring Boot 4: Event-Driven Architecture (Kafka) with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Advanced Spring Boot 4: Event-Driven Architecture (Kafka)?
No prior experience is required. Advanced Spring Boot 4: Event-Driven Architecture (Kafka) on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Implementing Dead Letter Topics (DLT)” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Advanced Spring Boot 4: Event-Driven Architecture (Kafka) lesson?
Yes. Every Advanced Spring Boot 4: Event-Driven Architecture (Kafka) lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Handling Consumer Exceptions
- Retry Mechanisms with Spring Retry
- Implementing Dead Letter Topics (DLT)
- Non-Blocking Retries with Retry Topics