miruky

Posted on Sep 12

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. This crop keeps only the name field so the full value remains readable at article width.

The Name field shows miruky-ddridapkwgegwklb.fifo. The .fifo suffix is required for a FIFO queue name. Queue type, content-based deduplication, and the timing controls are proved separately in the saved editor so the complete creation form does not have to be compressed into one image.

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. I used fixed, nonsensitive values so the returned body could be correlated without retaining service-generated identifiers.

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. The timing record begins at the observed acknowledgement, while generated message metadata stays outside the publication package.

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. The private monotonic timing record places the completed empty receive inside 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. Keep the full details header and generated identifiers outside the crop.

The selected Body tab shows delay-queue-proof. The pre-send form already establishes the message group, so the received-message image does not need the full attributes panel.

Next, verify whether this was the initial consumer-visible receive. A separate field crop can preserve that fact without retaining the Console-generated message ID or timestamps.

The separate attribute-only crop shows Receive count with value 1. The count supports this being the message's initial consumer-visible delivery. A private SHA-256 hash of the Console-generated message ID correlates the two crops without retaining the identifier.

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