Why use a message queue in cloud architecture?

A queue sits between a producer and a consumer. The producer writes a message and moves on; the consumer processes at its own rate. That absorbs spikes, isolates failures and lets you add consumers without changing the producer.

Delivery semantics

• At-most-once: a message may be lost but is never delivered twice
• At-least-once: a message is never lost but may be delivered more than once, so consumers must be idempotent
• Exactly-once: expensive and usually limited to a specific broker or processing model
• Visibility timeout: how long a consumer holds a message before it becomes visible again
• Dead-letter queue: captures messages that repeatedly fail so they do not loop forever

await sqs.sendMessage({
  QueueUrl: queueUrl,
  MessageBody: JSON.stringify(order),
  MessageAttributes: {
    eventType: { DataType: "String", StringValue: "order.created" },
  },
}).promise();

Queues change the failure model. The UI may accept a request before the work is done, so you need status tracking or optimistic UI. Poison messages, duplicate processing and out-of-order delivery need explicit handling.