Amazon SQS

If payment confirmation immediately calls receipt delivery, inventory updates, and recommendation refreshes, one slow downstream system can stall the whole request. Without a safe place to queue work during spikes, failures spread in chains.

Early systems often had APIs directly calling downstream tasks, but cascading failures were common as load increased. This made queue-based architectures that decouple producers and consumers and absorb work in between essential.

SQS stores messages in a queue for consumers to poll and process. Visibility timeouts, retries, and a DLQ isolate failures and absorb throughput spikes. Standard queues fit high throughput with at-least-once delivery, while FIFO queues fit flows that require ordering and stronger exactly-once processing semantics.

SQS and SNS are both messaging tools, but the processing model is different. SQS is a queue that holds individual tasks until consumers process them, while SNS immediately broadcasts an event to multiple targets. If you need to absorb producer and consumer speed differences and manage retries, look at SQS; if you need to spread the same event at once, look at SNS.

Well-suited for background jobs, async post-order processing, email sending, buffering, and pipelines that need retries. Not a good fit for broadcasting a single event to multiple consumers simultaneously.