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.