SQS.
SQS is AWS's managed message queue service, offering standard queues with at-least-once delivery and high throughput, and FIFO queues with ordering and exactly-once processing within a message group.
Where SQS fits on a long engagement.
Being fully managed is most of the value. No brokers to run, no clustering, no capacity planning, and effectively unlimited throughput on standard queues. For a great many workloads that removes the entire operational argument against introducing a queue.
Visibility timeout is the mechanism to understand. A consumed message is hidden rather than deleted, and reappears if not deleted within the timeout. Set shorter than processing time, the message is redelivered while still being processed — which produces duplicate work that looks inexplicable.
What an assigned team does with SQS.
Standard queues are at-least-once, so consumers must be idempotent. That is a design requirement rather than a configuration option, and assuming exactly-once delivery is the most common serious mistake with SQS.
Designing idempotency in from the start is far cheaper than retrofitting it, and it is the standard held under outsource software development services.
What we use SQS for.
- Queuing without operating a broker Managed infrastructure removing the operational argument against a queue.
- Visibility timeout matched to processing Timeouts set from real durations, so messages are not redelivered mid-work.
- Idempotent consumers by design Duplicate handling built in, because standard queues are at-least-once.
How SQS capacity is assigned.
Managed queuing is assigned inside development capacity, with consumer idempotency treated as a design requirement.
Tell us what your roadmap needs SQS for.
A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.
Loading the contact form… You can also email hello@azendo.co.
We reply within one working day. No obligation, and no newsletter.