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
Key features: visibility timeout (hide message while processing), dead-letter queues (capture failed messages), long polling (reduce empty receives), and message delay (delay delivery up to 15 minutes).
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.