Amazon SQS
Fully managed message queuing service for decoupling applications
SQS is like a post office mailbox for your applications. When one application needs to send work to another, instead of calling it directly (which fails if the receiver is busy or down), it drops a message in the SQS queue. The receiving application picks up messages when it's ready, processes them, and deletes them from the queue. It's perfect for decoupling systems: the sender doesn't wait for the receiver, and if the receiver crashes, messages stay safe in the queue. Think of it as a buffer between applications that smooths out traffic spikes and makes systems more resilient.
SQS provides two queue types: Standard (unlimited throughput, at-least-once delivery, best-effort ordering) and FIFO (up to 3,000 messages/second, exactly-once delivery, strict ordering). Messages can be up to 256KB (use S3 for larger payloads).
Key Capabilities
- Stores messages (up to 256KB) in queues for asynchronous decoupling between producers and consumers; consumers must explicitly delete messages after processing
- Standard queues offer high throughput with at-least-once delivery and best-effort ordering; FIFO queues guarantee exactly-once processing and strict message order at up to 3,000 messages/second with batching
- Visibility timeout hides a message from other consumers while one consumer is processing it; if not deleted within the timeout, the message reappears for reprocessing
- Dead-letter queues (DLQs) automatically move messages that fail processing after a configurable number of retries, isolating poison-pill messages for inspection
- Long polling waits up to 20 seconds for a message before returning an empty response, reducing the cost and volume of empty poll requests
- Delay queues postpone message delivery to consumers by up to 15 minutes, useful for workflows that require a processing buffer after an event
Gotchas & Constraints
Gotcha #1: Standard queues can deliver messages out of order and more than once; design consumers to be idempotent. Gotcha #2: Messages are retained for 4 days by default (max 14 days); don't use SQS for long-term storage. Constraints: FIFO queues limited to 3,000 messages/second (300/second per API action), message size limited to 256KB, and maximum 120,000 in-flight messages per queue.
An e-commerce site processes orders: validate inventory, charge credit card, send confirmation email, and update analytics. Previously, the order service called each system synchronously; if email service was slow, order confirmation took 10 seconds. Worse, if payment service crashed, orders were lost. They implement SQS: when an order is placed, the order service publishes a message to an SQS queue and immediately returns success to the user. Four consumer services poll the queue: inventory service, payment service, email service, and analytics service. Each processes messages independently at their own pace. During Black Friday, 10,000 orders/minute flood in; SQS buffers them, and consumers process them over 30 minutes without being overwhelmed. When the payment service crashes, messages stay in the queue; when it recovers, it processes backlogged messages. Failed messages (e.g., invalid credit cards) go to a dead-letter queue for manual review.
The Result
95% faster order confirmation, zero lost orders, and resilient architecture.