Amazon SQS é um serviço de filas gerenciadas; Amazon SNS é um serviço de notificações pub/sub. Juntos, eles formam a base da mensageria desacoplada na AWS — permitindo que serviços se comuniquem sem depender da disponibilidade uns dos outros.

🎯 Para a certificação

Questões sobre SQS e SNS testam se você entende a diferença entre "empurrar" (SNS) e "puxar" (SQS) mensagens, o padrão fanout, Standard vs FIFO, o papel do visibility timeout no ciclo de vida de uma mensagem, como configurar dead-letter queues corretamente (inclusive o maxReceiveCount), e quando usar SQS/SNS em vez de EventBridge.

---

Resumo

Pense no SNS como uma rádio ao vivo e no SQS como uma caixa de correio. Uma rádio (SNS) transmite uma mensagem uma única vez, e qualquer ouvinte inscrito (e-mail, SMS, uma fila SQS, uma função Lambda) a recebe no mesmo instante — se ninguém estiver ouvindo naquele momento, a mensagem se perde. Uma caixa de correio (SQS), por outro lado, guarda a carta até que alguém venha buscá-la — não importa se o destinatário está de férias por uma semana, a carta continua lá, esperando.

• SNS: push, pub/sub, entrega imediata a múltiplos subscribers (SQS, Lambda, HTTP/S, e-mail, SMS). Não retém mensagem se ninguém está inscrito.
• SQS: pull, fila, retém a mensagem até que um consumidor a processe e a delete explicitamente. Existe em duas variantes: Standard (alto throughput, at-least-once) e FIFO (ordenação garantida, exactly-once).
• Fanout: o padrão mais cobrado na prova — um tópico SNS publica uma vez, e várias filas SQS inscritas recebem cópias independentes, permitindo processamento paralelo e desacoplado.

---

1. Dois modelos de entrega: push (SNS) vs pull (SQS)

A diferença mais fundamental entre os dois serviços não é "fila vs notificação" — é quem inicia a entrega da mensagem.

• SNS empurra (push): no momento em que uma mensagem é publicada num tópico, a AWS já tenta entregá-la ativamente a cada subscriber inscrito. Não há "buscar" — a mensagem chega sozinha.
• SQS é puxado (pull): uma mensagem colocada numa fila fica parada lá, esperando. Nada acontece com ela até que um consumidor chame ReceiveMessage ativamente (ou, no caso de uma Lambda com event source mapping, até que o serviço faça esse polling por você, por trás dos panos).

Essa diferença tem uma consequência prática importante: SNS não é durável para quem não está ouvindo. Se um tópico SNS publica uma mensagem e nenhum subscriber está inscrito (ou o subscriber está indisponível no momento), a mensagem simplesmente não é entregue — não existe "retenção" no SNS como existe no SQS. Por isso, o padrão mais seguro é quase sempre inscrever uma fila SQS como subscriber de um tópico SNS, mesmo quando o consumidor final é outra coisa: a fila garante que a mensagem sobrevive até ser processada, mesmo que o consumidor caia temporariamente.

---

2. Ciclo de vida de uma mensagem no SQS: visibility timeout

Esse é o conceito mais mal-entendido do SQS, e um dos mais cobrados na prova.

Quando um consumidor chama ReceiveMessage, a mensagem não é removida da fila — ela apenas fica invisível para outros consumidores por um período configurável chamado visibility timeout (padrão: 30 segundos). A ideia é dar tempo ao consumidor para processar a mensagem antes de confirmar que terminou.

O que acontece depois depende do que o consumidor faz:

• Consumidor processa com sucesso e chama DeleteMessage: a mensagem é removida permanentemente da fila.
• Consumidor falha, trava, ou simplesmente não chama DeleteMessage a tempo: quando o visibility timeout expira, a mensagem volta a ficar visível na fila automaticamente, e outro consumidor (ou o mesmo) pode recebê-la de novo. Isso é o mecanismo que dá ao SQS sua entrega at-least-once: a mensagem só some quando alguém explicitamente confirma que terminou.

💡 Para a prova: se o cenário descreve uma mensagem sendo processada duas vezes porque o consumidor demorou mais que o esperado, a causa quase sempre é um visibility timeout configurado baixo demais em relação ao tempo real de processamento. A correção é aumentar o visibility timeout (idealmente para pelo menos o dobro do tempo médio de processamento da função consumidora).

💡 Mensagens acima de 256 KB não cabem diretamente no SQS — a solução para "mensagens grandes" é o Amazon SQS Extended Client Library, que armazena o payload real num bucket S3 e envia apenas uma referência (ponteiro) através da fila.

---

3. Standard vs FIFO

Dois detalhes que a prova adora testar:

• A ordenação do FIFO é por message group, não pela fila inteira. Se você não especificar um MessageGroupId, todas as mensagens caem no mesmo grupo e são processadas estritamente em sequência (limitando o paralelismo). Se você usar IDs de grupo diferentes (ex: um por cliente), mensagens de grupos diferentes podem ser processadas em paralelo, mas a ordem dentro de cada grupo continua garantida.
• "Exactly-once" no FIFO é sobre não introduzir duplicatas na fila, não uma garantia mágica de que o consumidor nunca vai processar algo duas vezes por qualquer motivo (ex: se o consumidor falhar depois de processar mas antes de deletar a mensagem, ela ainda pode voltar a ficar visível). Por isso, mesmo com FIFO, projetar consumidores idempotentes continua sendo boa prática.

---

4. Padrões: Fanout e Pub/Sub

4.1 Fanout (SNS → múltiplas SQS)

O padrão mais cobrado da prova para SQS/SNS juntos. Um único tópico SNS publica uma mensagem, e ela é replicada automaticamente para todas as filas SQS inscritas — cada fila recebe sua própria cópia independente.

Explicação didática: imagine um comunicado da empresa (SNS) que precisa chegar simultaneamente ao setor de faturamento, ao setor de atendimento e ao setor de analytics — cada um com sua própria "caixa de entrada" (fila SQS). O comunicado é anunciado uma única vez, mas cada setor processa sua cópia no seu próprio ritmo, sem que um dependa do outro e sem que o publicador precise saber quantos ou quais setores estão ouvindo.

Por que usar fanout em vez de publicar direto em cada fila? Porque o publicador fica desacoplado do número e da identidade dos consumidores. Adicionar um quarto setor consumidor (ex: um novo serviço de auditoria) significa apenas inscrever uma nova fila SQS no tópico existente — nenhuma mudança é necessária no lado de quem publica.

4.2 Pub/Sub direto (sem fila intermediária)

SNS também entrega diretamente a endpoints HTTP/S, e-mail, SMS ou Lambda, sem passar por uma fila. É mais simples, mas menos resiliente: se o endpoint estiver indisponível no momento da publicação, a entrega pode falhar sem um buffer para reter a mensagem (embora o SNS tenha retry automático com backoff para HTTP/S e Lambda, ele não é ilimitado).

---

5. Dead-letter queues (DLQ)

Uma DLQ captura mensagens que não puderam ser processadas com sucesso após um número configurável de tentativas — permitindo diagnóstico e reprocessamento posterior, sem perder o dado nem travar a fila principal indefinidamente com uma mensagem "problemática".

5.1 DLQ de uma fila SQS

Configurada através de uma redrive policy, que define:

• Fila de destino (a própria DLQ, que é outra fila SQS comum).
• maxReceiveCount: quantas vezes uma mensagem pode ser recebida (e voltar a ficar visível sem ser deletada) antes de ser movida automaticamente para a DLQ.

Se uma mensagem está sendo recebida repetidamente e nunca deletada (ex: o consumidor trava toda vez que tenta processá-la), ela seria reprocessada para sempre sem uma DLQ configurada — bloqueando efetivamente o consumidor de avançar para outras mensagens "boas" atrás dela na fila.

5.2 DLQ associada ao SNS

SNS também suporta DLQ, mas com propósito diferente: captura mensagens que falharam na entrega a um subscriber específico (ex: um endpoint HTTP que retornou erro repetidamente, ou uma Lambda que falhou em todas as tentativas de invocação assíncrona vindas do SNS).

💡 Não confunda a DLQ da fila SQS (mensagens que o consumidor não conseguiu processar) com a DLQ do SNS (mensagens que o SNS não conseguiu entregar a um subscriber). São mecanismos parecidos na ideia, mas resolvem problemas em pontos diferentes do fluxo.

---

6. Segurança e permissões

• Resource-based policy (queue/topic policy): controla quem pode publicar ou consumir — por exemplo, permitir que um bucket S3 específico publique eventos numa fila SQS, ou que um tópico SNS só aceite publicações de uma role específica.
• Criptografia (SSE): tanto SQS quanto SNS suportam server-side encryption com KMS, protegendo o conteúdo da mensagem em repouso.
• IAM policy na role do consumidor/publicador continua sendo necessária além da resource policy — assim como no Lambda, a permissão de "quem pode chamar" (resource policy) e "o que a entidade pode fazer" (IAM policy do usuário/role) são camadas independentes.

---

7. Integração com Lambda

• SQS → Lambda: sempre via event source mapping (invocação baseada em polling) — o serviço Lambda faz o polling da fila por trás dos panos e invoca a função com um lote de mensagens. Se o processamento falhar, as mensagens voltam a ficar visíveis na fila (não são deletadas) e podem ser reprocessadas até o maxReceiveCount, quando então vão para a DLQ da própria fila SQS.
• SNS → Lambda: invocação assíncrona direta (push) — o SNS invoca a função e, em caso de falha após os retries automáticos do Lambda, o evento pode ser roteado para o destino de falha configurado na própria função (ou para a DLQ do SNS, se configurada no lado do subscriber).

💡 Para a prova: se o cenário menciona uma Lambda consumindo uma fila SQS que tem mensagens "presas" sendo reprocessadas indefinidamente, verifique o maxReceiveCount da redrive policy e confirme se existe uma DLQ configurada para capturar essas mensagens.

---

8. Quando usar SQS, SNS ou EventBridge

• Use SQS quando você precisa de um buffer confiável entre produtor e consumidor, especialmente quando o consumidor processa no seu próprio ritmo (worker pulling de uma fila) ou quando picos de carga precisam ser absorvidos sem sobrecarregar o consumidor.
• Use SNS quando você precisa notificar múltiplos destinos diferentes em tempo real a partir de um único evento, especialmente quando os destinos são heterogêneos (e-mail, SMS, HTTP, filas).
• Considere EventBridge em vez de SNS quando o cenário envolve roteamento baseado em conteúdo/regras entre múltiplos produtores e consumidores de diferentes serviços AWS ou SaaS de terceiros, ou quando você precisa de um barramento de eventos com schema registry — SNS é mais simples e direto para fanout puro, EventBridge é mais adequado para arquiteturas orientadas a eventos mais complexas.

---

9. Boas práticas

• Prefira o padrão SNS → SQS → worker em vez de push direto (SNS → HTTP) quando resiliência importa mais que latência mínima — a fila absorve indisponibilidades temporárias do consumidor.
• Configure DLQ com maxReceiveCount em toda fila de produção, evitando que uma mensagem "envenenada" bloqueie o processamento das demais.
• Ajuste o visibility timeout para ser maior que o tempo médio (idealmente com folga) de processamento do consumidor, evitando reentregas duplicadas por timeout prematuro.
• Projete consumidores idempotentes — mesmo com FIFO, falhas no meio do processamento podem levar a reentregas.
• Use FIFO com message group ID apenas quando ordering realmente importa para o caso de uso — caso contrário, Standard oferece throughput maior sem necessidade real.
• Use long polling (ReceiveMessageWaitTimeSeconds > 0) em vez de short polling, reduzindo custo com chamadas vazias e latência de entrega.

---

10. Como cai na certificação

• Cenário "replicar um evento para múltiplos serviços consumirem de forma independente" → Fanout: SNS com múltiplas filas SQS inscritas.
• Cenário "mensagens sendo processadas fora de ordem" ou "processamento duplicado indevido para o mesmo cliente" → SQS FIFO com message group ID.
• Cenário "mensagem sendo reprocessada repetidamente sem nunca ter sucesso, travando a fila" → configurar DLQ com maxReceiveCount adequado.
• Cenário "consumidor recebe a mesma mensagem mais de uma vez, mesmo processando com sucesso" → revisar o visibility timeout, provavelmente configurado abaixo do tempo real de processamento.
• Cenário "mensagens maiores que 256 KB" → SQS Extended Client Library com payload no S3.
• Cenário "notificar múltiplos tipos de destino (e-mail, SMS, fila, HTTP) a partir de um único evento" → SNS.
• Cenário "roteamento baseado em regras/conteúdo entre múltiplos serviços e origens" → considerar EventBridge em vez de SNS.
• Cenário "Lambda consumindo SQS com falhas persistentes num pequeno subconjunto de mensagens" → verificar redrive policy e DLQ da fila, não apenas o destino de falha da função Lambda.

---

11. Exercícios práticos

1. Desenhe um sistema de e-commerce em que um evento de "pedido criado" precisa disparar processamento independente em faturamento, envio de e-mail e atualização de estoque. Identifique o padrão e os componentes envolvidos.
2. Explique, com um exemplo concreto, por que uma fila SQS Standard pode entregar a mesma mensagem duas vezes mesmo sem nenhum erro do consumidor.
3. Um consumidor demora em média 45 segundos para processar cada mensagem, mas a fila está configurada com visibility timeout de 30 segundos. Explique o sintoma que isso provavelmente está causando e como corrigir.
4. Compare o comportamento de um tópico SNS sem nenhuma fila SQS inscrita publicando para um endpoint HTTP indisponível, contra o mesmo cenário usando o padrão SNS→SQS→worker.
5. Explique a diferença entre a DLQ de uma fila SQS e a DLQ associada a um subscriber do SNS.

---

12. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Laboratório Prático

Objetivo: implementar o padrão fanout (SNS → múltiplas filas SQS) e observar o comportamento de reentrega causado por um visibility timeout mal dimensionado.

Pré-requisitos: conta AWS com permissão para SNS, SQS e IAM.

Tempo estimado: 25 minutos

Possíveis custos: praticamente nulo dentro do free tier para poucas mensagens de teste.

Passos:

1. Crie um tópico SNS (ex: pedido-criado).
2. Crie duas filas SQS (ex: fila-faturamento e fila-notificacao) e inscreva ambas como subscribers do tópico SNS.
3. Publique uma mensagem de teste no tópico e confirme, no console, que ambas as filas receberam uma cópia independente da mesma mensagem.
4. Em uma das filas, reduza o visibility timeout para um valor bem baixo (ex: 5 segundos).
5. Simule um consumidor lento: receba a mensagem (ReceiveMessage) e espere mais tempo que o visibility timeout antes de tentar deletá-la.
6. Observe que a mensagem volta a ficar visível na fila antes de você conseguir deletá-la — reproduzindo, na prática, o comportamento de reentrega por timeout mal dimensionado.
7. Corrija aumentando o visibility timeout para um valor maior que o tempo de processamento simulado, e repita o teste confirmando que a reentrega não ocorre mais.

Resultado esperado: você observa na prática tanto o padrão fanout (uma publicação, múltiplas cópias independentes) quanto a causa mais comum de mensagens duplicadas no SQS Standard.

Limpeza dos recursos: delete as duas filas SQS e o tópico SNS criados.

---

Referências:

• Amazon SQS Developer Guide: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
• Amazon SNS Developer Guide: https://docs.aws.amazon.com/sns/latest/dg/welcome.html
• SQS Visibility Timeout: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
• SQS Dead-letter queues: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html
• SNS Fanout pattern: https://docs.aws.amazon.com/sns/latest/dg/sns-common-scenarios.html
• SQS Extended Client Library: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/s3-messages.html