SQS: filas gerenciadas na AWS sem precisar de infraestrutura

O que é SQS e por que usar filas gerenciadas

Mensageria sem servidor para escalar a zero

O Amazon Simple Queue Service (SQS) é um serviço de filas totalmente gerenciado da AWS que elimina a necessidade de provisionar, configurar e operar servidores de mensageria. Ao contrário do RabbitMQ ou Kafka auto-hospedados, o SQS escala automaticamente para qualquer volume de mensagens, desde zero até bilhões de mensagens por dia, sem intervenção operacional. O modelo de precificação é baseado em consumo: você paga por requisição de API, tornando o custo proporcional ao uso real. A integração nativa com outros serviços AWS como Lambda, SNS, ECS e EventBridge torna o SQS o backbone natural de arquiteturas serverless e microsserviços na nuvem da Amazon.

Standard vs FIFO queues

Escolhendo o tipo certo de fila para cada caso

O SQS oferece dois tipos de fila com características distintas. Standard Queues oferecem throughput praticamente ilimitado (quase infinitas mensagens por segundo), entrega at-least-once (uma mensagem pode ser entregue mais de uma vez em casos raros) e ordenacao de melhor esforco, sem garantia de sequência. FIFO Queues garantem que mensagens sejam processadas exatamente na ordem em que foram enviadas e com entrega exactly-once, eliminando duplicatas via deduplication ID. FIFO Queues têm throughput limitado a 3.000 mensagens por segundo com batching ou 300 sem. A escolha entre Standard e FIFO deve considerar se o seu processamento é idempotente (Standard suficiente) ou se a ordem e exatamente-uma-vez sao requisitos de negocio.

Visibility timeout — evitar processamento duplicado

O mecanismo de lock temporario do SQS

Quando um consumer recebe uma mensagem do SQS, ela se torna invisível para outros consumers por um período chamado visibility timeout (padrão: 30 segundos). Se o consumer processar e deletar a mensagem antes do timeout expirar, a operação é concluída com sucesso. Se o consumer falhar ou o timeout expirar sem deleção, a mensagem volta a ficar visível e pode ser recebida por outro consumer. Esse mecanismo de lock temporário é o que garante que mensagens nao sejam processadas simultaneamente por múltiplos consumers. O visibility timeout deve ser configurado com folga em relação ao tempo médio de processamento; use ChangeMessageVisibility para extendê-lo dinamicamente quando o processamento demora mais que o esperado.

Long polling — reduzindo custo e latência

Como receber mensagens de forma eficiente

Por padrão, a chamada ReceiveMessage do SQS retorna imediatamente mesmo se nao houver mensagens disponíveis, resultando em polling curto (short polling) que consome requisições de API desnecessárias e aumenta custo. Long polling (WaitTimeSeconds entre 1 e 20 segundos) mantém a conexão aberta por até 20 segundos aguardando mensagens, retornando assim que uma mensagem chega ou o timeout expira. Long polling reduz o número de requisições vazias em até 80%, diminuindo custo e latência de entrega simultaneamente. Configure sempre WaitTimeSeconds=20 em ambientes de producao, exceto quando latência sub-segundo é um requisito crítico que justifique o custo maior do short polling.

Dead letter queues no SQS

Isolando mensagens que falham repetidamente

O SQS suporta dead letter queues nativas configuradas através de uma Redrive Policy: quando uma mensagem é recebida mais vezes que o limite configurado (maxReceiveCount) sem ser deletada, ela é automaticamente movida para a dead letter queue associada. A DLQ deve ser do mesmo tipo da fila de origem (Standard com Standard, FIFO com FIFO) e tipicamente é monitorada via CloudWatch Alarm que dispara quando o ApproximateNumberOfMessagesVisible da DLQ é maior que zero. O SQS também oferece o recurso Dead Letter Queue Redrive, que permite reprocessar mensagens da DLQ de volta à fila original após corrigir o bug que causava a falha, sem necessidade de código customizado para esse fluxo.

Message attributes e filtering

Metadados e filtros para roteamento de mensagens

Mensagens no SQS podem incluir até 10 atributos customizados (message attributes) com tipos String, Number ou Binary, que funcionam como metadados estruturados sem fazer parte do corpo da mensagem. Esses atributos permitem que consumers filtrem mensagens antes de processar o payload completo, reduzindo processamento desnecessário. Quando o SQS é integrado com SNS via subscricao com filter policy, consumidores recebem apenas mensagens cujos atributos correspondem aos filtros configurados, criando um sistema de roteamento por conteúdo sem alterar o publisher. Essa combinacao SNS + SQS com filter policies é o padrao de fan-out seletivo mais usado em arquiteturas event-driven na AWS.

SQS com Lambda — processamento serverless

Integracao nativa para escala automatica

A integracao entre SQS e Lambda é um dos padroes mais poderosos da AWS: o Event Source Mapping do Lambda faz polling automatico da fila e invoca funcoes Lambda com batches de mensagens conforme chegam. Lambda escala automaticamente o número de instancias em execucao com base no volume da fila, ate o limite configurado de concorrencia. Em caso de falha de processamento de um item do batch, o comportamento de reporting de falhas parciais (reportBatchItemFailures) permite indicar quais mensagens específicas falharam, evitando reprocessamento de mensagens que ja foram processadas com sucesso no mesmo batch. Essa integracao elimina completamente a necessidade de gerenciar polling, scaling e infraestrutura de consumers.

SQS FIFO e deduplicacao

Garantindo exatamente-uma-vez em filas ordenadas

FIFO Queues implementam deduplicacao baseada em MessageDeduplicationId: mensagens com o mesmo ID enviadas dentro de uma janela de 5 minutos sao descartadas automaticamente, garantindo exatamente-uma-vez. O ID pode ser fornecido explicitamente pelo producer ou gerado automaticamente via hash SHA-256 do corpo da mensagem com content-based deduplication ativado. Message Groups (MessageGroupId) permitem processamento paralelo dentro de uma FIFO Queue: mensagens do mesmo grupo sao processadas em ordem estrita, enquanto grupos diferentes podem ser processados em paralelo. Isso permite alta vazao em FIFO Queues quando o caso de uso tem múltiplos fluxos independentes que precisam de ordenacao interna mas nao entre si.

Monitoramento com CloudWatch

Visibilidade operacional de filas SQS

O CloudWatch disponibiliza automaticamente métricas essenciais do SQS sem configuracao adicional: ApproximateNumberOfMessagesVisible (mensagens aguardando processamento), ApproximateAgeOfOldestMessage (idade da mensagem mais antiga, indicador crítico de atraso) e NumberOfMessagesSent/Deleted (throughput). Configure alarmes no ApproximateAgeOfOldestMessage para detectar situations onde o consumer está mais lento que o producer, e no ApproximateNumberOfMessagesVisible da DLQ para alertar sobre falhas de processamento. O AWS X-Ray, integrado nativamente com Lambda e SQS, fornece rastreamento distribuído de ponta a ponta, permitindo visualizar o caminho completo de uma mensagem desde o envio ate o processamento final.

Conclusao — SQS como base de arquiteturas assíncronas na AWS

Quando SQS é a escolha certa

SQS é a escolha ideal quando a simplicidade operacional e a integracao nativa com o ecossistema AWS sao prioridades. A ausência de gestao de infraestrutura, o scaling automatico e a precificacao por uso tornam o SQS imbatível para equipes que preferem focar em lógica de negocio em vez de operacao de middleware. Continue em: Fundamentos obrigatórios antes de produção.