SQS

SQS is a managed message queue. It lets one part of your system send work to another part without those two parts needing to be running at the same time or at the same speed. Messages sit in the queue until a consumer is ready to process them.

The Problem It Solves

Imagine an e-commerce site where placing an order triggers five things: charge the card, update inventory, send a confirmation email, notify the warehouse, and generate an invoice. If you do all five synchronously in the checkout request, any one of them failing or being slow ruins the user's experience.

SQS lets you decouple these steps. The checkout service puts a "new order" message in a queue and immediately returns success to the user. Each downstream service reads from the queue at its own pace, processes the message, and deletes it when done. If the invoice service crashes, the message stays in the queue and gets retried automatically — the user's order isn't lost.

Standard vs FIFO Queues

SQS offers two queue types with a fundamental trade-off:

Standard queues offer virtually unlimited throughput and at-least-once delivery. Messages may occasionally be delivered out of order or more than once, so your consumers need to handle duplicates. Use these for high-volume workloads where exact ordering doesn't matter — log processing, sending notifications, background jobs.

FIFO queues guarantee exactly-once processing and strict ordering. Messages are delivered in the exact order they were sent and never duplicated. The trade-off is lower throughput (300 messages/second, or 3,000 with batching). Use these for financial transactions, inventory updates, or any workflow where order and exactly-once semantics matter.

Key Concepts

Visibility timeout — when a consumer reads a message, SQS hides it from other consumers for a set period. If the consumer finishes and deletes the message, it's gone. If the consumer crashes before deleting it, the timeout expires and the message becomes visible again for another consumer to retry.

Dead Letter Queue (DLQ) — a separate queue where messages are sent after failing a configurable number of times. Instead of a bad message blocking your queue forever, it moves to the DLQ where you can inspect it, understand why it failed, and decide what to do with it.

Long polling — instead of constantly asking "any messages yet?", consumers can wait up to 20 seconds for a message to arrive. This reduces empty responses and API costs significantly.