Dead letter queues in HLD - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding the purpose of Dead Letter Queues (DLQs)

What is the primary purpose of a Dead Letter Queue in a messaging system?

A To prioritize urgent messages over regular ones

B To capture messages that cannot be processed after multiple attempts

C To store messages that have been successfully processed

D To temporarily hold messages before processing

💡 Hint

Think about what happens to messages that repeatedly fail processing.

Dead Letter Queues are designed to hold messages that fail processing multiple times, so they can be inspected or retried later without blocking the main queue.

❓ Architecture

intermediate

Designing a system with Dead Letter Queues

In a distributed messaging system, where should the Dead Letter Queue be placed to ensure reliable message handling?

A Inside the main queue to store all messages temporarily

B As a backup storage for all processed messages

C Before the main queue to filter messages

D As a separate queue that receives messages after maximum retry attempts fail

💡 Hint

Consider when messages are moved to the DLQ in the processing lifecycle.

The DLQ should be a separate queue that receives messages only after they fail processing multiple times, ensuring the main queue remains clean.

❓ scaling

advanced

Handling high volume of messages in Dead Letter Queues

What is the best approach to handle a sudden surge of messages landing in the Dead Letter Queue to avoid system overload?

A Throttle DLQ processing and prioritize messages based on failure reasons

B Process all DLQ messages immediately in parallel without limits

C Delete all DLQ messages to free up space quickly

D Merge DLQ messages back into the main queue without filtering

💡 Hint

Think about controlled processing and prioritization to maintain stability.

Throttling DLQ processing and prioritizing messages based on failure reasons helps avoid overload and allows focused recovery.

❓ tradeoff

advanced

Tradeoffs in configuring retry policies before Dead Letter Queue routing

Which tradeoff is most relevant when deciding the number of retry attempts before sending a message to the Dead Letter Queue?

A Unlimited retries guarantee all messages are processed successfully

B Fewer retries always improve system throughput without downsides

C More retries increase processing latency but reduce message loss risk

D Retries have no impact on system resources or message handling

💡 Hint

Consider how retries affect processing time and resource use.

More retries can delay message processing and increase resource use but help avoid losing messages that might succeed later.

❓ estimation

expert

Estimating Dead Letter Queue storage requirements

A messaging system processes 1 million messages per hour. Historically, 0.1% of messages fail and are sent to the Dead Letter Queue. Each message averages 2 KB in size. What is the estimated storage needed for DLQ messages per day?

A Approximately 48 MB per day

B Approximately 4.8 GB per day

C Approximately 480 MB per day

D Approximately 4.8 MB per day

💡 Hint

Calculate failed messages per day and multiply by message size.

Failed messages per hour = 1,000,000 * 0.001 = 1,000. Per day = 1,000 * 24 = 24,000 messages. Storage = 24,000 * 2 KB = 48,000 KB ≈ 48 MB per day.

Practice

1. What is the primary purpose of a dead letter queue in a messaging system?

easy

A. To store messages that failed processing after retries

B. To speed up message delivery

C. To permanently delete all messages

D. To encrypt messages for security

Solution

1. Step 1: Understand message failure handling

   Messages that cannot be processed successfully after several attempts need a place to be stored for later analysis.

2. Step 2: Identify dead letter queue role

   A dead letter queue holds these failed messages separately to keep the main queue clean and allow troubleshooting.

3. Final Answer:

   To store messages that failed processing after retries -> Option A

4. Quick Check:

   Dead letter queue = store failed messages [OK]

Hint: Dead letter queues hold failed messages after retries [OK]

Common Mistakes:

• Thinking dead letter queues speed up delivery
• Confusing dead letter queue with message deletion
• Assuming dead letter queues encrypt messages

2. Which of the following is the correct way to configure a dead letter queue in a messaging system?

easy

A. Send all messages directly to the dead letter queue

B. Set a retry limit and specify a dead letter queue destination

C. Disable retries and delete messages immediately

D. Encrypt messages before sending to the main queue

Solution

1. Step 1: Understand retry and dead letter queue setup

   To avoid infinite retries, systems set a retry limit and then route failed messages to a dead letter queue.

2. Step 2: Identify correct configuration

   Setting a retry limit and specifying a dead letter queue destination is the standard approach.

3. Final Answer:

   Set a retry limit and specify a dead letter queue destination -> Option B

4. Quick Check:

   Retry limit + dead letter queue = correct config [OK]

Hint: Set retry limit and dead letter queue destination [OK]

Common Mistakes:

• Disabling retries without dead letter queue
• Sending all messages to dead letter queue
• Confusing encryption with dead letter queue setup

3. Consider this pseudocode for message processing with a dead letter queue:

for message in queue:
  if process(message) == false:
    if message.retry_count < 3:
      message.retry_count += 1
      queue.push(message)
    else:
      dead_letter_queue.push(message)

What happens to a message that fails processing 4 times?

medium

A. It is deleted immediately after the first failure

B. It stays in the main queue indefinitely

C. It is moved to the dead letter queue after the 4th failure

D. It is retried infinitely without limit

Solution

1. Step 1: Analyze retry logic in pseudocode

   The code retries messages while retry_count is less than 3, increasing retry_count each time.

2. Step 2: Determine action after 4 failures

   After 3 failures (retry_count incremented to 3 and enqueued), on the 4th failure retry_count=3 (not < 3), so it is pushed to the dead letter queue.

3. Final Answer:

   It is moved to the dead letter queue after the 4th failure -> Option C

4. Quick Check:

   Retry count 3 triggers dead letter queue [OK]

Hint: Retry count limit sends message to dead letter queue [OK]

Common Mistakes:

• Assuming message stays in main queue forever
• Thinking message deletes after first failure
• Believing retries are unlimited

4. A system uses a dead letter queue but notices some messages never appear there even after multiple failures. What is the most likely cause?

medium

A. Dead letter queue is deleting messages immediately

B. Dead letter queue is receiving all messages correctly

C. Messages are processed successfully on first try

D. The retry limit is set too high or missing

Solution

1. Step 1: Understand missing dead letter messages

   If failed messages never reach the dead letter queue, it suggests retries never stop or dead letter routing is not triggered.

2. Step 2: Identify retry limit impact

   Without a retry limit, messages keep retrying and never move to dead letter queue.

3. Final Answer:

   The retry limit is set too high or missing -> Option D

4. Quick Check:

   Missing retry limit = no dead letter queue usage [OK]

Hint: Check retry limit if dead letter queue empty [OK]

Common Mistakes:

• Assuming dead letter queue always receives all messages
• Ignoring retry limit configuration
• Confusing successful processing with dead letter queue issues

5. You design a system with a dead letter queue to handle failed messages. Which approach best prevents message loss and supports troubleshooting?

hard

A. Set a retry limit, route failed messages to dead letter queue, and log failure reasons

B. Delete messages immediately after failure to save storage

C. Retry messages infinitely without dead letter queue

D. Send all messages to dead letter queue first, then to main queue

Solution

1. Step 1: Identify reliable failure handling

   Setting a retry limit avoids infinite loops and routing failed messages to a dead letter queue preserves them for analysis.

2. Step 2: Add logging for troubleshooting

   Logging failure reasons helps diagnose issues and improves system reliability.

3. Final Answer:

   Set a retry limit, route failed messages to dead letter queue, and log failure reasons -> Option A

4. Quick Check:

   Retry limit + dead letter queue + logging = best practice [OK]

Hint: Combine retry limit, dead letter queue, and logging [OK]

Common Mistakes:

• Deleting messages immediately losing data
• Retrying infinitely causing processing loops
• Sending all messages to dead letter queue first