In RabbitMQ, delayed retry (or delay scheduling) using a Dead Letter Exchange (DLX) is a common pattern to retry failed messages after a specified delay, without requiring a plugin like the rabbitmq_delayed_message_exchange.
Purpose
When a message processing fails (e.g. a consumer throws an error), instead of dropping or immediately retrying the message, we can delay its retry to allow time for recovery (e.g., temporary system issues, downstream service downtime).
Delay Retry with DLX — Overview
RabbitMQ does not natively support delayed queues, but using TTL (Time-To-Live) and Dead Letter Exchanges, you can simulate this behavior.
1. Primary Queue (Main Queue)
This is where the original message is sent.
2. Retry Queue
This queue holds the message temporarily before it’s sent back to the main queue for reprocessing. Messages are set with a TTL.
3. Dead Letter Exchange (DLX)
When a message expires (TTL is reached), RabbitMQ routes it to a dead letter exchange, which is configured to send it back to the main queue.
How It Works
Step-by-Step:
- Message fails in the consumer from the main queue.
- You republish the failed message to a retry queue with:
- A TTL (e.g., 10 seconds).
- The queue is configured with a DLX that routes messages back to the main queue.
- After the TTL, the message expires and gets routed via DLX to the main queue.
- The consumer retries the message.
Queue Configuration Example
Retry Queue (with TTL & DLX)
{
"x-dead-letter-exchange": "main-exchange",
"x-dead-letter-routing-key": "main.queue",
"x-message-ttl": 10000 // 10 seconds delay
}Main Queue
{
"queue": "main.queue",
"exchange": "main-exchange"
}Benefits
- No plugin needed (uses built-in RabbitMQ features).
- Flexible: different delay levels can be configured (e.g., 10s, 30s, 60s).
- Simple to set up and maintain.
Considerations
- Each delay duration requires a separate queue.
- Messages are not invisible—they stay in the retry queue until TTL expires.
- Repeated failures can cause infinite retry loops if not capped.