Dead letter queues in Spring Boot - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when a message is rejected without requeue in a Spring Boot RabbitMQ listener with DLQ configured?

Consider a Spring Boot application using RabbitMQ with a dead letter queue (DLQ) configured. If a message listener rejects a message without requeueing it, what is the expected behavior?

Spring Boot

public void listen(String message) {
    if(message.contains("fail")) {
        throw new RuntimeException("Processing failed");
    }
    System.out.println("Processed: " + message);
}

A The message is sent to the dead letter queue for later inspection.

B The message is discarded and lost permanently.

C The message is requeued and retried indefinitely.

D The message is logged but remains in the original queue.

💡 Hint

Think about what happens to messages that cannot be processed and are rejected without requeue.

When a message is rejected without requeue in RabbitMQ with DLQ configured, it is routed to the dead letter queue. This allows later inspection or handling of failed messages.

📝 Syntax

intermediate

Which Spring Boot annotation correctly configures a dead letter queue for a RabbitMQ listener?

You want to configure a dead letter queue for a RabbitMQ listener in Spring Boot. Which annotation usage is correct?

A @RabbitListener(queues = "myQueue", dlq = "myDLQ")

B @RabbitListener(queues = "myQueue", deadLetterExchange = "dlx")

C

@RabbitListener(bindings = @QueueBinding(value = @Queue(value = "myQueue", durable = true, arguments = {
    @Argument(name = "x-dead-letter-exchange", value = "dlx")
})))

D @RabbitListener(queues = "myQueue", deadLetterQueue = "myDLQ")

💡 Hint

Dead letter queues are configured via queue arguments in Spring AMQP.

Dead letter queues are set by adding the x-dead-letter-exchange argument to the queue declaration. Option C shows the correct way to do this using @QueueBinding and @Argument.

❓ state_output

advanced

What is the state of the message after max retry attempts are exceeded with DLQ configured?

In a Spring Boot RabbitMQ setup with a dead letter queue and retry mechanism, what happens to a message after it exceeds the maximum retry attempts?

A The message is moved to the dead letter queue for further analysis.

B The message is marked as processed and ignored.

C The message is deleted from the queue and lost.

D The message is sent back to the original queue for infinite retries.

💡 Hint

Consider what happens when retries fail repeatedly in a system with DLQ.

When the retry attempts are exhausted, the message is routed to the dead letter queue to avoid infinite retry loops and allow manual or automated handling.

🔧 Debug

advanced

Why does the dead letter queue not receive messages despite configuration?

A Spring Boot application has a dead letter queue configured for RabbitMQ, but messages that fail processing are not appearing in the DLQ. What is the most likely cause?

A The DLQ is not bound to the dead letter exchange.

B The message TTL is set too high.

C The listener method is not throwing exceptions on failure.

D The original queue is missing the x-dead-letter-exchange argument in its declaration.

💡 Hint

Check the queue arguments and bindings carefully.

If the original queue does not have the x-dead-letter-exchange argument, RabbitMQ does not know where to route rejected messages, so the DLQ will not receive them.

🧠 Conceptual

expert

What is the primary benefit of using a dead letter queue in a Spring Boot microservice architecture?

Why is it important to use dead letter queues in a Spring Boot microservice system that processes messages asynchronously?

A To permanently discard all failed messages and reduce queue size.

B To isolate and analyze failed messages without blocking the main processing flow.

C To automatically retry failed messages indefinitely until success.

D To encrypt messages for secure transmission between services.

💡 Hint

Think about how failures should be handled without stopping the system.

Dead letter queues allow failed messages to be separated from the main queue so they can be inspected or reprocessed later without blocking or crashing the main message processing.