Today, we launch a new set of APIs for Amazon SQS. These new APIs allow you to manage dead-letter queue (DLQ) redrive programmatically. You can now use the AWS SDKs or the AWS Command Line Interface (AWS CLI) to programmatically move messages from the DLQ to their original queue, or to a custom queue destination, to attempt to process them again. A DLQ is a queue where Amazon SQS automatically moves messages that are not correctly processed by your consumer application.
To fully appreciate how this new API might help you, let’s have a quick look back at history.
Message queues are an integral part of modern application architectures. They allow developers to decouple services by allowing asynchronous and message-based communications between message producers and consumers. In most systems, messages are persisted in shared storage (the queue) until the consumer processes them. Message queues allow developers to build applications that are resilient to temporary service failure. They help prioritize message processing and scale their fleet of worker nodes that process the messages. Message queues are also popular in event-driven architectures.
Asynchronous message exchange is not new in application architectures. The concept of exchanging messages asynchronously between applications appeared in the 1960s and was first made popular when IBM launched TCAM for OS/360 in 1972. The general adoption came 20 years later with IBM MQ Series in 1993 (now IBM MQ) and when Sun Microsystems released Java Messaging Service (JMS) in 1998, a standard API for Java applications to interact with message queues.
AWS launched Amazon SQS on July 12, 2006. Amazon SQS is a highly scalable, reliable, and elastic queuing service that “just works.” As Werner wrote at the time: “We have chosen a concurrency model where the process working on a message automatically acquires a leased lock on that message; if the message is not deleted before the lease expires, it becomes available for processing again. Makes failure handling very simple.”
On January 29, 2014, we introduced dead-letter queues (DLQ). DLQs help you avoid a message that failed to be processed from staying forever on top of the queue, possibly preventing other messages in the queue from processing. With DLQs, each queue has an associated property telling Amazon SQS how many times a message may be presented for processing (maxReceiveCount). Each message also has an associated receive counter (ReceiveCount). Each time a consumer application picks up a message for processing, the message receive count is incremented by 1. When ReceiveCount > maxReceiveCount, Amazon SQS moves the message to your designated DLQ for human analysis and debugging. You generally associate alarms with the DLQ to send notifications when such events happen. Typical reasons to move a message to the DLQ are because they are incorrectly formatted, there are bugs in the consumer application, or it takes too long to process the message.
At AWS re:Invent 2021, AWS announced dead-letter queue redrive on the Amazon SQS console. The redrive addresses the second part of the failed message lifecycle. It allows you to reinject the message in its original queue to attempt processing it again. After the consumer application is fixed and ready to consume the failed messages, you can redrive the messages from the DLQ back in the source queue or a customized queue destination. It just requires a couple of clicks on the console.
Today, we are adding APIs allowing you to write applications and scripts that handle the redrive programmatically. There is no longer a need to have a human clicking on the console. Using the API increases the scalability of your processes and reduces the risk of human error.
Let’s See It in Action
To try out this new API, I open a terminal for a command-line only demo. Before I get started, I make sure I have the latest version of the AWS CLI. On macOS I enter brew upgrade awscli.
I first create two queues. One is the dead-letter queue, and the other is my application queue:
# First, I create the dead-letter queue (notice the -dlq I choose to add at the end of the queue name)
➜ ~ aws sqs create-queue
–queue-name awsnewsblog-dlq
{
“QueueUrl”: “https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog-dlq”
}
# second, I retrieve the Arn of the queue I just created
➜ ~ aws sqs get-queue-attributes
–queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog-dlq
–attribute-names QueueArn
{
“Attributes”: {
“QueueArn”: “arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq”
}
}
# Third, I create the application queue. I enter a redrive policy: post messages in the DLQ after three delivery attempts
➜ ~ aws sqs create-queue
–queue-name awsnewsblog
–attributes ‘{“RedrivePolicy”: “{“deadLetterTargetArn”:”arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq”,”maxReceiveCount”:”3″}”}’
{
“QueueUrl”: “https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog”
}
Now that the two queues are ready, I post a message to the application queue:
➜ ~ aws sqs send-message
–queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog
–message-body “Hello World”
{
“MD5OfMessageBody”: “b10a8db164e0754105b7a99be72e3fe5”,
“MessageId”: “fdc26778-ce9a-4782-9e33-ae73877cfcb2”
}
Next, I consume the message, but I don’t delete it from the queue. This simulates a crash in the message consumer application. Message consumers are supposed to delete the message after successful processing. I set the maxReceivedCount property to 3 when I entered the redrivePolicy. I therefore repeat this operation three times to force Amazon SQS to move the message to the dead-letter queue after three delivery attempts. The default visibility timeout is 30 seconds, so I have to wait 30 seconds or more between the retries.
➜ ~ aws sqs receive-message
–queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog
{
“Messages”: [
{
“MessageId”: “fdc26778-ce9a-4782-9e33-ae73877cfcb2”,
“ReceiptHandle”: “AQEBP8yOfgBlnjlkGXjyeLROiY7xg7cZ6Znq8Aoa0d3Ar4uvTLPrHZptNotNfKRK25xm+IU8ebD3kDwZ9lja6JYs/t1kBlwiNO6TBACN5srAb/WggQiAAkYl045Tx3CvsOypbJA3y8U+MyEOQRwIz6G85i7MnR8RgKTlhOzOZOVACXC4W8J9GADaQquFaS1wVeM9VDsOxds1hDZLL0j33PIAkIrG016LOQ4sAntH0DOlEKIWZjvZIQGdlRJS65PJu+I/Ka1UPHGiFt9f8m3SR+Y34/ttRWpQANlXQi5ByA47N8UfcpFXXB5L30cUmoDtKucPewsJNG2zRCteR0bQczMMAmOPujsKq70UGOT8X2gEv2LfhlY7+5n8z3yew8sdBjWhVSegrgj6Yzwoc4kXiMddMg==”,
“MD5OfBody”: “b10a8db164e0754105b7a99be72e3fe5”,
“Body”: “Hello World”
}
]
}
# wait 30 seconds,
# then repeat two times (for a total of three receive-message API calls)
After three processing attempts, the message is not in the queue anymore:
➜ ~ aws sqs receive-message
–queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog
{
“Messages”: []
}
The message has been moved to the dead-letter queue. I check the DLQ to confirm (notice the queue URL ending with -dlq):
➜ ~ aws sqs receive-message
–queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog-dlq
{
“Messages”: [
{
“MessageId”: “fdc26778-ce9a-4782-9e33-ae73877cfcb2”,
“ReceiptHandle”: “AQEBCLtBMoZYVMMq7fUGNHeCliqE3mFXnkuJ+nOXLK1++uoXWBG31nDejCpxElmiBZWfbcfGJrEdKj4P9HJdrQMYDbeSqB+u1ZlB7CYzQBiQps4SEG0biEoubwqjQbmDZlPrmkFsnYgLD98D1XYWk/Ik6Z2n/wxDo9ko9rbZ15izK5RFnbwveNy8dfc6ireqVB1EGbeGkHcweHGuoeKWXEab1ynZWhNqZsQgCR6pWRkgtn59lJcLv4cJ4UMewNzvt7tMHH69GvVjXdYDYvJJI2vj+6RHvcvSHWWhTNT+CuPEXguVNuNrSya8gho1fCnKpVwQre6HhMlLPjY4wvn/tXY7+5rmte9eXagCqLQXaENB2R7qWNVPiWRIJy8/cTf37NLYVzBom030DNJlH9EeceRhCQ==”,
“MD5OfBody”: “b10a8db164e0754105b7a99be72e3fe5”,
“Body”: “Hello World”
}
]
}
Now that the setup is ready, let’s programmatically redrive the message to its original queue. Let’s assume I understand why the consumer didn’t correctly process the message and that I fixed the consumer application code. I use start-message-move-task on the DLQ to start the asynchronous redrive. There is an optional attribute (MaxNumberOfMessagesPerSecond) to control the velocity of the redrive:
➜ ~ aws sqs start-message-move-task
–source-arn arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq
{
“TaskHandle”: “eyJ0YXNrSWQiOiI4ZGJmNjBiMy00MmUwLTQzYTYtYjg4Zi1iMTZjYWRjY2FkNmEiLCJzb3VyY2VBcm4iOiJhcm46YXdzOnNxczp1cy1lYXN0LTI6NDg2NjUyMDY2NjkzOmF3c25ld3NibG9nLWRscSJ9”
}
I can list and check status the of the move tasks I initiated with list-message-move-tasks or cancel a running task by calling the cancel-message-move-task API:
➜ ~ aws sqs list-message-move-tasks
–source-arn arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq
{
“Results”: [
{
“Status”: “COMPLETED”,
“SourceArn”: “arn:aws:sqs:us-east-2:012345678900:awsnewsblog-dlq”,
“ApproximateNumberOfMessagesMoved”: 1,
“ApproximateNumberOfMessagesToMove”: 1,
“StartedTimestamp”: 1684135792239
}
]
}
Now my application can consume the message again from the application queue:
➜ ~ aws sqs receive-message
–queue-url https://sqs.us-east-2.amazonaws.com/012345678900/awsnewsblog
{
“Messages”: [
{
“MessageId”: “a7ae83ca-cde4-48bf-b822-3d4bc1f4dcae”,
“ReceiptHandle”: “AQEB9a+Dm2nvb3VUn9+46j9UsDidU/W6qFwJtXtNWTyfoSDOKT7h73e6ctT9RVZysEw3qqzJOx1cxblTTOSrYwwwoBA2qoJMGsqsrsRGGYojBvf9X8hqi8B8MHn9rTm8diJ2wT2b7WC+TDrx3zIvUeiSEkP+EhqyYOvOs7Q9aETR+Uz02kQxZ/cUJWsN4MMSXBejwW+c5ivv5uQtpfUrfZuCWa9B9O67Kj/q52clriPHpcqCCfJwFBSZkGTXYwTpnjxD4QM7DPS+xVeVfTyM7DsKCAOtpvFBmX5m4UNKT6TROgCnGxTRglUSMWQp8ufVxXiaUyM1dwqxYekM9uX/RCb01gEyCZHas4jeNRV5nUJlhBkkqPlw3i6w9Uuc2y9nH0Df8nH3g7KTXo4lv5Bl3ayh9w==”,
“MD5OfBody”: “b10a8db164e0754105b7a99be72e3fe5”,
“Body”: “Hello World”
}
]
}
Availability
DLQ redrive APIs are available today in all commercial Regions where Amazon SQS is available.
Redriving the messages from the dead-letter queue to the source queue or a custom destination queue generates additional API calls billed based on existing pricing (starting at $0.40 per million API calls, after the first million, which is free every month). Amazon SQS batches the messages while redriving them from one queue to another. This makes moving messages from one queue to another a simple and low-cost option.
To learn more about DLQ and DLQ redrive, check our documentation.
Remember that we live in an asynchronous world—so should your applications. Get started today and write your first redrive application.
