Dead letter queue pattern in Kafka - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this Kafka consumer code snippet?

Consider a Kafka consumer configured to process messages from a topic. If a message processing fails, it is sent to a dead letter queue (DLQ). What will be the output after processing the following messages?

Kafka

from kafka import KafkaConsumer, KafkaProducer

consumer = KafkaConsumer('main_topic', bootstrap_servers='localhost:9092')
producer = KafkaProducer(bootstrap_servers='localhost:9092')

def process_message(msg):
    if msg == b'bad_message':
        raise ValueError('Processing failed')
    return msg.decode('utf-8').upper()

for message in consumer:
    try:
        result = process_message(message.value)
        print(f'Processed: {result}')
    except Exception as e:
        producer.send('dead_letter_queue', message.value)
        print(f'Message sent to DLQ: {message.value.decode("utf-8")}')
    break  # For this example, process only one message

A Processed: bad_message

B Processed: GOOD_MESSAGE

C Message sent to DLQ: bad_message

D No output, consumer hangs

💡 Hint

Think about what happens when process_message raises an exception.

The code tries to process the message. If the message is b'bad_message', it raises an error and sends the message to the dead letter queue, printing the DLQ message.

🧠 Conceptual

intermediate

What is the main purpose of a dead letter queue in Kafka?

Choose the best description of why a dead letter queue (DLQ) is used in Kafka message processing.

A To store all successfully processed messages for auditing

B To capture messages that cannot be processed due to errors

C To temporarily hold messages before processing

D To speed up message consumption by parallel processing

💡 Hint

Think about what happens to messages that cause errors during processing.

A dead letter queue is used to capture messages that fail processing so they can be inspected or retried later without blocking the main processing flow.

🔧 Debug

advanced

Why does this Kafka consumer fail to send messages to the dead letter queue?

Examine the following Kafka consumer code snippet. It is supposed to send failed messages to a dead letter queue, but it never does. What is the cause?

Kafka

from kafka import KafkaConsumer, KafkaProducer

consumer = KafkaConsumer('main_topic', bootstrap_servers='localhost:9092')
producer = KafkaProducer(bootstrap_servers='localhost:9092')

def process_message(msg):
    if msg == b'error':
        raise Exception('Error')
    return msg.decode('utf-8')

for message in consumer:
    try:
        print(process_message(message.value))
    except Exception:
        producer.send('dead_letter_queue', message.value)
producer.flush()

A The producer.send() is asynchronous and flush() is never called inside the loop, so messages remain buffered

B The producer.flush() is called outside the loop, so messages are never sent

C The consumer is not subscribed to the dead letter queue topic

D The process_message function does not raise exceptions properly

💡 Hint

Consider how KafkaProducer sends messages asynchronously and when they are actually sent.

KafkaProducer.send() is asynchronous. Without calling flush() after send(), messages may stay buffered and not be sent immediately. Since flush() is called only once after the loop, if the loop never ends or exceptions occur, messages may not be sent.

📝 Syntax

advanced

Which option correctly defines a Kafka consumer with a dead letter queue handler in Python?

Choose the code snippet that correctly sets up a Kafka consumer that sends failed messages to a dead letter queue.

A

consumer = KafkaConsumer('topic', bootstrap_servers='localhost:9092')
producer = KafkaProducer(bootstrap_servers='localhost:9092')
for msg in consumer:
    try:
        process(msg.value)
    except:
        producer.send('dlq', msg.value)
        producer.flush()

B

consumer = KafkaConsumer('topic', bootstrap_servers='localhost:9092')
producer = KafkaProducer(bootstrap_servers='localhost:9092')
for msg in consumer:
    try:
        process(msg.value)
    except:
        producer.send('dlq', msg.value)
producer.flush()

C

consumer = KafkaConsumer('topic', bootstrap_servers='localhost:9092')
producer = KafkaProducer(bootstrap_servers='localhost:9092')
for msg in consumer:
    try:
        process(msg.value)
    except Exception as e:
        producer.send('dlq', msg.value)
        producer.flush()

D

consumer = KafkaConsumer('topic', bootstrap_servers='localhost:9092')
producer = KafkaProducer(bootstrap_servers='localhost:9092')
for msg in consumer:
    try:
        process(msg.value)
    except Exception:
        producer.send('dlq', msg.value)
        producer.flush()

💡 Hint

Look for correct exception handling syntax and proper flush usage inside the loop.

Option D correctly catches exceptions with except Exception: and calls producer.flush() inside the except block to ensure messages are sent immediately to the DLQ.

🚀 Application

expert

How many messages will be in the dead letter queue after processing this batch?

A Kafka consumer processes a batch of 5 messages: ['ok', 'fail', 'ok', 'fail', 'fail']. The process_message function raises an exception for 'fail' messages, which are sent to the dead letter queue. How many messages will the dead letter queue contain after processing all 5?

Kafka

messages = [b'ok', b'fail', b'ok', b'fail', b'fail']
failed_messages = []

def process_message(msg):
    if msg == b'fail':
        raise Exception('Failed')
    return msg.decode('utf-8')

for msg in messages:
    try:
        process_message(msg)
    except Exception:
        failed_messages.append(msg)

print(len(failed_messages))

A 3

B 1

C 2

D 0

💡 Hint

Count how many messages cause exceptions.

There are 3 'fail' messages in the list. Each causes an exception and is added to the dead letter queue list, so the count is 3.

Practice

1. What is the main purpose of a Dead Letter Queue (DLQ) in Kafka?

easy

A. To store messages that failed processing for later analysis

B. To speed up message processing by duplicating messages

C. To permanently delete messages after processing

D. To encrypt messages before sending to consumers

Solution

1. Step 1: Understand the role of DLQ

   A Dead Letter Queue is used to hold messages that cannot be processed successfully by the main consumer.

2. Step 2: Identify the purpose of storing failed messages

   Storing failed messages allows developers to analyze and fix issues without blocking the main processing flow.

3. Final Answer:

   To store messages that failed processing for later analysis -> Option A

4. Quick Check:

   DLQ = store failed messages [OK]

Hint: DLQ holds failed messages to avoid blocking main flow [OK]

Common Mistakes:

• Thinking DLQ speeds up processing by duplicating messages
• Confusing DLQ with message deletion
• Assuming DLQ encrypts messages

2. Which Kafka configuration is commonly used to specify the Dead Letter Queue topic for a consumer?

easy

A. enable.auto.commit

B. auto.offset.reset

C. max.poll.records

D. dead.letter.queue.topic.name

Solution

1. Step 1: Identify DLQ related configuration

   The configuration dead.letter.queue.topic.name is used to specify the topic where failed messages are sent.

2. Step 2: Differentiate from other common configs

   Other options like enable.auto.commit and auto.offset.reset control offset behavior, not DLQ.

3. Final Answer:

   dead.letter.queue.topic.name -> Option D

4. Quick Check:

   DLQ topic config = dead.letter.queue.topic.name [OK]

Hint: DLQ topic config usually contains 'dead.letter.queue' phrase [OK]

Common Mistakes:

• Confusing offset configs with DLQ topic config
• Using unrelated consumer configs for DLQ
• Assuming DLQ is automatic without config

3. Given the following Kafka consumer code snippet, what happens when message processing fails?

try {
  processMessage(record);
} catch (Exception e) {
  producer.send(new ProducerRecord<>("dlq-topic", record.key(), record.value()));
}

medium

A. The message is silently dropped without notification

B. The message is retried immediately in the same consumer loop

C. The failed message is sent to the "dlq-topic" for later review

D. The consumer stops processing all messages

Solution

1. Step 1: Analyze the catch block behavior

   When an exception occurs, the code sends the failed message to the "dlq-topic" using a producer.

2. Step 2: Understand the effect on message processing

   The message is not retried or dropped silently; it is stored in the DLQ topic for later analysis.

3. Final Answer:

   The failed message is sent to the "dlq-topic" for later review -> Option C

4. Quick Check:

   Exception handling sends message to DLQ [OK]

Hint: Catch block sends failed messages to DLQ topic [OK]

Common Mistakes:

• Assuming immediate retry happens automatically
• Thinking consumer stops on failure
• Believing message is dropped silently

4. Identify the error in this Kafka consumer code snippet that tries to send failed messages to a DLQ:

try {
  process(record);
} catch (Exception e) {
  producer.send("dlq-topic", record.key(), record.value());
}

medium

A. The catch block should rethrow the exception

B. The producer.send method is missing a ProducerRecord object

C. The process method should not be inside try-catch

D. The record.key() cannot be used as a message key

Solution

1. Step 1: Check the producer.send method usage

   The producer.send method requires a ProducerRecord object, not separate parameters.

2. Step 2: Identify correct usage

   The correct call is producer.send(new ProducerRecord<>("dlq-topic", record.key(), record.value()));

3. Final Answer:

   The producer.send method is missing a ProducerRecord object -> Option B

4. Quick Check:

   producer.send needs ProducerRecord object [OK]

Hint: producer.send requires ProducerRecord, not separate args [OK]

Common Mistakes:

• Passing topic and data as separate arguments to send
• Ignoring exception handling best practices
• Misusing record key as invalid

5. You want to implement a Dead Letter Queue pattern in Kafka that retries failed messages up to 3 times before sending them to the DLQ. Which approach correctly achieves this?

hard

A. Use a retry counter in message headers; on failure increment and retry, else send to DLQ after 3 tries

B. Send all failed messages immediately to DLQ without retries

C. Configure Kafka broker to automatically retry messages 3 times before DLQ

D. Use a separate consumer that deletes messages after 3 retries

Solution

1. Step 1: Understand retry logic with DLQ

   Retries require tracking how many times a message was processed; using headers to count retries is common.

2. Step 2: Implement conditional retry or DLQ send

   If retry count is less than 3, retry processing; if 3 or more, send message to DLQ topic.

3. Step 3: Evaluate other options

   Kafka broker does not handle retries automatically; immediate DLQ send skips retries; deleting messages after retries is incorrect.

4. Final Answer:

   Use a retry counter in message headers; on failure increment and retry, else send to DLQ after 3 tries -> Option A

5. Quick Check:

   Retry count in headers controls DLQ after 3 tries [OK]

Hint: Track retries in headers; send to DLQ after max retries [OK]

Common Mistakes:

• Expecting Kafka broker to retry automatically
• Sending all failures immediately to DLQ
• Deleting messages instead of sending to DLQ