---
title: "SQS | Skills We Assign For | Azendo"
description: "SQS for managed queuing — visibility timeouts, FIFO versus standard, plus the Azendo roles assigned for it."
url: "https://azendo.co/skills/sqs/"
---

[Skills](https://azendo.co/skills/) APIs and integration 

# 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](https://azendo.co/services/software-development/).

## 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.

## Roles we assign SQS for

* [Integration Engineer AI automation engineering](https://azendo.co/services/ai-automation-engineering/integration-engineer/)

## Service lines it sits in

* [AI automation engineering](https://azendo.co/services/ai-automation-engineering/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in apis and integration

* [webhooks — skill we assign for](https://azendo.co/skills/webhooks/)
* [Kafka — skill we assign for](https://azendo.co/skills/kafka/)
* [API design — skill we assign for](https://azendo.co/skills/api-design/)
* [message queues — skill we assign for](https://azendo.co/skills/message-queues/)
* [FastAPI — skill we assign for](https://azendo.co/skills/fastapi/)
* [RabbitMQ — skill we assign for](https://azendo.co/skills/rabbitmq/)
* [API gateways — skill we assign for](https://azendo.co/skills/api-gateways/)
* [API integration — skill we assign for](https://azendo.co/skills/api-integration/)

## 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.

[All skills we assign for](https://azendo.co/skills/)