SQS

SQS buffers asynchronous work between Node.js producers and consumers. Standard queues offer best-effort ordering and at-least-once delivery; FIFO queues guarantee order and exactly-once processing within a message group.

After a consumer receives a message, a visibility timeout hides it from others. Extend the timeout for long jobs or delete on success. Failed messages land in a dead-letter queue after `maxReceiveCount` for inspection and replay.

| Pattern | Detail | |---------|--------| | Idempotent handler | Same message twice must be safe | | Long polling | `WaitTimeSeconds` reduces empty receives | | DLQ | Poison messages without blocking the queue |

Common in event-driven APIs: HTTP handler enqueues a job, worker Lambda or ECS task processes it, status stored in DynamoDB or Postgres.

On interviews: visibility timeout tuning, FIFO throughput limits, partial batch failures with Lambda, and idempotency keys in Node.js workers.

Common pitfalls: visibility shorter than job duration causing duplicate work; no DLQ; assuming exactly-once on standard queues; unbounded queue depth without alarms.

The trade-off is simple durable decoupling versus no pub-sub fan-out (pair with SNS) and operational attention to poison messages.

Checklist:

• Size visibility timeout to p99 processing time.
• Configure DLQ and monitor ApproximateAgeOfOldestMessage.
• Make consumers idempotent with deduplication stores.
• Use long polling to cut cost and latency.