Decoupling with queues and events · Chapter 1 of 3
How queues buffer unpredictable spikes
Placing a queue between services converts immediate outages into manageable processing delays and protects downstream systems.
FoundationsBuilds the idea from nothing. No prior AWS assumed.
Decoupling services with message queues
How does a queue prevent a downstream outage from crashing your frontend?
Producers publish order events asynchronously into standard SQS queue.
- 01
The synchronous call failure path
If your frontend web server calls a payment processing API directly, any slowdown or outage in the payment API will cause connections to pile up on the web server, taking it down.
- 02
Asynchronous buffering with SQS
By placing an Simple Queue Service queue between the services, the frontend writes a message to the queue and immediately returns a success status to the user. The worker process retrieves messages at its own pace.
- 03
Graceful degradation under load
If traffic spikes, the queue size grows, but the system stays online. Users experience a delay in processing rather than a flat connection error or website crash.
Check yourself
What is the main benefit of decoupling two services using an SQS queue?
Under the hoodThe same thing from underneath: limits, failure modes, numbers.
Visibility timeouts and dead letter queue routing
How does SQS handle processing failures and duplicate messages?
Producers publish order events asynchronously into standard SQS queue.
- 01
The visibility timeout window
When a worker retrieves a message, SQS makes the message invisible to other workers for a set period. The worker must process the message and delete it from the queue before this timeout expires.
- 02
Why visibility timeout causes duplicate processing
If a worker takes longer to process a message than the visibility timeout, the message becomes visible to other workers. A second worker will retrieve the message, causing duplicate processing.
- 03
The necessity of dead letter queues
If a message cannot be processed due to a code bug, it will continuously fail and return to the queue. A dead-letter queue isolates these bad messages after a set number of retries, allowing you to debug them.
The numbers
- Maximum message size
- 1 MiB1,048,576 bytes per message. For larger work payloads, store data in S3 and send a reference.
- Maximum retention period
- 14 daysMessages are automatically deleted from the queue if they are not processed within this window.
- Maximum visibility timeout
- 12 hoursThe maximum duration you can configure for a message to remain hidden during processing.
- FIFO throughput limit
- 3,000 requests per secondThe default limit for FIFO queues when using batching; standard queues have unlimited throughput.
Check yourself
A worker retrieves a message from an SQS queue, but the application crashes midway through processing. What happens to the message?
Official references & further reading
These lessons simplify selected behaviors for learning. Verify current service limits, Region support and production requirements with the official references. Experiments describe their own assumptions.
Report an error or suggest a clearer explanation →