miruky

Posted on Sep 12 Edited on Sep 19

Watch an Amazon SQS Delay Queue Hold a Message Before Delivery

#aws #sqs #eventdriven #tutorial

Introduction

Hi, I'm miruky.

An Amazon SQS delay queue hides a new message before its initial delivery. That sounds similar to a visibility timeout, but the clock starts at a different moment: delivery delay starts when the message enters the queue, while visibility timeout starts after a consumer receives it.

This run makes the distinction visible with one FIFO queue. I use one fixed body, one timed receive during the delay, and one later receive after the delay.

I use FIFO deliberately. A Standard-queue send can set a message timer that overrides the queue delay, while FIFO queues do not support per-message timers. That leaves the queue's 60 s setting as the only initial delay in this test.

The exercise sends one message and makes a few SQS requests. Current request pricing and free-tier terms are linked below.

1. Create a FIFO delay queue

Begin in the English AWS Console and keep the complete run in the N. Virginia Region.

The header confirms United States (N. Virginia) while the SQS Console is in English. Its Region code is us-east-1, which remains fixed for the queue and every message operation in this run.

Before creation, check that the generated queue name is unused. This keeps the observed queue state separate from any existing resource.

The exact filter for miruky-ddridapkwgegwklb.fifo returns no queue. That empty result establishes the resource boundary before creation.

Create a FIFO queue with the generated name.

The Name field shows miruky-ddridapkwgegwklb.fifo. The .fifo suffix is required for a FIFO queue name. Check the queue type, content-based deduplication, and timing controls in the saved settings before sending a message.

Finish the queue with a 60 s delivery delay, a 20 s receive wait, a 30 s visibility timeout, and content-based deduplication. Reopen the saved settings before sending so the evidence reflects the stored configuration rather than unsaved form input.

The saved editor retains FIFO, a delivery-delay value of 1 with unit Minutes, a receive wait of 20 with unit Seconds, and enabled Content-based deduplication. The one-minute value is the same 60 s delay entered during creation. FIFO queues do not support per-message timers, so a send cannot replace the queue delay with an individual value.

2. Send one message through the FIFO queue

Prepare one FIFO message in the same Console tab. Use a fixed body so you can match the received message to this send.

The send form contains delay-queue-proof under Message body and delay-group under Message group ID. The Message deduplication ID - optional field is empty. With content-based deduplication enabled, SQS derives the deduplication ID from the message body.

Submit the form exactly once, then start the initial receive as soon as the send operation returns. Measure elapsed time from the observed send acknowledgement.

3. Poll while the delivery delay is active

Start one long poll immediately after the send acknowledgement. The saved queue setting lets a receive wait up to 20 seconds; it does not mean the Console operation must consume exactly 20 seconds.

The receive panel shows Messages (0) and No messages. To view messages in the queue, poll for messages. A monotonic timer measured from the send acknowledgement places the completed empty receive within the queue's configured 60 s delay.

No receive has succeeded yet, so the queue's 30 s visibility timeout has not started. This empty result occurs before consumer delivery, unlike an in-flight message hidden after receipt.

Long polling queries all SQS servers and reduces false empty responses. The controlled timing, single message, and later successful receive connect this observation to the configured delay without treating one receive as an absolute distributed-system guarantee.

4. Receive the message after the delay

Wait at least 65 seconds from the send acknowledgement, adding a small margin beyond the configured 60 seconds. Poll again on the same page without sending another message or editing the queue.

The later receive summary shows Messages (1) without any queue edit or additional send. The attempt started 65.001 seconds after the acknowledgement, and the only changed input was elapsed time.

Open the received item and compare its body with the fixed send value.

The selected Body tab shows delay-queue-proof. This body matches the value entered in the send form.

Check the receive count to determine whether this was the initial consumer-visible receive.

The message attributes show Receive count with value 1. The count supports this being the message's initial consumer-visible delivery. The body and receive-count screenshots refer to the same message, matched by the SHA-256 hash of its generated message ID. The ID itself is omitted.

Wrap-up

The queue accepted the message immediately but withheld it from receives for its configured 60 s delay. The initial long poll was empty, while the later poll returned the fixed body with approximate receive count 1.

Delay queues are useful when every new message needs a short initial hold. For longer or calendar-based scheduling, AWS recommends EventBridge Scheduler instead of stretching SQS delay behavior beyond its supported maximum.

Thanks for reading this far.

See you in the next one.

Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.

DEV Community