Queues

Cloud queues (SQS, Pub/Sub subscriptions, Azure Service Bus) decouple producers from consumers for email sends, image processing, webhooks, and outbox patterns. Messages are at-least-once — consumers must be idempotent and handle visibility timeouts, retries, and dead-letter queues (DLQ).

					async function handleJob(payload: JobPayload) {
  const key = payload.idempotencyKey;
  if (await store.alreadyProcessed(key)) return;
  await sendEmail(payload);
  await store.markProcessed(key);
}
				

| Setting | Risk if wrong | |---------|-----------------| | Visibility timeout | Duplicate processing or stuck messages | | Max receive count | Poison messages never reach DLQ | | Batch size | Partial batch failure handling | | FIFO ordering | Throughput limits per group |

Node workers poll or use push (Lambda, Cloud Functions). Log correlation IDs across enqueue and process. Monitor DLQ depth as a product signal, not only infra noise.

On interviews: at-least-once vs exactly-once myths, idempotency keys, DLQ replay strategy, backpressure when consumers lag, and queue vs event bus choice.

Common pitfalls: non-idempotent side effects; visibility shorter than max job time; no alerting on DLQ growth; huge JSON payloads instead of S3 pointer pattern.

The trade-off is resilient async scaling versus distributed debugging complexity and duplicate-delivery semantics.

Checklist:

• Design idempotent handlers with dedupe store.
• Tune visibility to p99 job duration.
• Route poison messages to DLQ with alerts.
• Keep messages small; store blobs in object storage.