Queue (SQS)
Run slow work in the background so it never blocks a request
Queue (SQS)
A queue lets your app hand off slow work to be done in the background instead of making the user wait. Your service drops a message on the queue and responds immediately; a worker picks the message up and does the actual work a moment later.
It's built on AWS SQS, which keeps messages safe until they've been processed.
When you need it
- Sending email or notifications — don't make the user wait for the email to send.
- Processing uploads — resize an image or scan a document after the upload returns.
- Calling slow third-party APIs — retry in the background without failing the request.
- Anything that can happen "soon" rather than "right now."
Pair a queue with a worker service: the web/API service enqueues jobs, and the worker drains them.
How it connects
Link the queue to a service and StrictOps injects the queue URL:
Producers send messages to QUEUE_URL; the worker reads from the same URL. Link the queue to both the service that creates jobs and the worker that processes them.
Settings explained
- Type — Standard delivers at high throughput and is the right default. FIFO guarantees strict order and exactly-once processing; only choose it when order truly matters (and it's slower).
- Retention — how long an unprocessed message waits in the queue before it's dropped. The default (4 days) gives your worker plenty of time to catch up after an outage.
- Dead-letter queue — a holding area for messages that repeatedly fail to process, so a single bad job doesn't get retried forever. Keep this on so failures are visible instead of silent.
Cost guidance
Queues are billed per message and are very cheap for typical workloads. A dead-letter queue adds negligible cost and is worth keeping on.