CodePark/ questions / SQS, SNS & EventBridge
START PRACTICINGPRACTICE
Backend question · Cloud & AWS › SQS, SNS & EventBridge

Walk through how a Node worker consumes SQS messages. Explain visibility timeout, long polling and dead-letter queues.

The worker runs a loop with three steps:

  • It calls ReceiveMessage to get messages.
  • It processes each message.
  • It calls DeleteMessage with the message's receipt handle.

SQS never deletes a message by itself after delivering it. The worker must delete it.

When the worker receives a message, the message becomes invisible to other workers for the visibility timeout. If the worker deletes it in time, it is gone. If the worker crashes or is too slow, the message becomes visible again and SQS delivers it again. Set the timeout longer than normal processing time. For long jobs, extend it with ChangeMessageVisibility.

Long polling means setting WaitTimeSeconds, up to 20 seconds. The call then waits for messages to arrive, instead of returning an empty response at once. This cuts cost and the number of empty responses.

A dead-letter queue (DLQ) is a separate queue for messages that keep failing. A redrive policy moves a message to the DLQ after it has been received maxReceiveCount times. This stops poison messages (messages that always fail) from looping forever. Set an alarm on the DLQ depth, and redrive the messages back after you fix the bug.

  • The worker receives a message, processes it, then deletes it explicitly.
  • The visibility timeout hides in-flight messages. When it expires, SQS delivers the message again.
  • Extend the visibility timeout for long work.
  • Long polling with WaitTimeSeconds reduces empty receives and cost.
  • A redrive policy with maxReceiveCount sends poison messages to a DLQ.