EventBridge, SQS e SNS: qual, quando, como combinar
⏱ 12 min·⭐ 55 XP
Pré-requisitos (0/1)0%
- ⬜🔀 Step Functions: orquestração de workflows(AWS Developer Associate (DVA-C02))
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Comparação
| Feature | SQS | SNS | EventBridge |
|---|---|---|---|
| Modelo | Queue (pull) | Pub/Sub (push) | Event bus (pattern match) |
| Ordem | FIFO opcional | Sem | Sem |
| Durabilidade | Até 14 dias | Transient | Transient + archive 365d |
| Fan-out | Não | Sim, trivial | Sim, com filters |
| Filtros | Não | Basic attributes | Content-based rico |
| Schema | N/A | N/A | Registry + codegen |
| Preço | $0.40/M | $0.50/M | $1.00/M |
| Use case | Decouple async processing | Notificações simples | Event-driven moderno |
FeatureModelo
SQSQueue (pull)
SNSPub/Sub (push)
EventBridgeEvent bus (pattern match)
FeatureOrdem
SQSFIFO opcional
SNSSem
EventBridgeSem
FeatureDurabilidade
SQSAté 14 dias
SNSTransient
EventBridgeTransient + archive 365d
FeatureFan-out
SQSNão
SNSSim, trivial
EventBridgeSim, com filters
FeatureFiltros
SQSNão
SNSBasic attributes
EventBridgeContent-based rico
FeatureSchema
SQSN/A
SNSN/A
EventBridgeRegistry + codegen
FeaturePreço
SQS$0.40/M
SNS$0.50/M
EventBridge$1.00/M
FeatureUse case
SQSDecouple async processing
SNSNotificações simples
EventBridgeEvent-driven moderno
ProdutorVPC
Serviço de pedidospublica "PedidoCriado"
Distribuição
SNS Topicentrega a todos os assinantes
Uma fila por consumidor
Fila · faturamentoritmo próprio
Fila · estoqueritmo próprio
Fila · e-mailritmo próprio
Consumidores
Faturamento
Estoque
Notificação
Quando falha
DLQ por filaisola a falha de cada consumidor
- → publica uma vez
- → poll
- → poll
- → poll
- → após maxReceiveCount
- Compute
- Integração de apps
O padrão fan-out é SNS + SQS, não SNS sozinho. A fila é o que transforma "entreguei" em "vai ser processado mesmo que o consumidor esteja fora" — e é a razão pela qual esta é a resposta canônica de notificação confiável.
- O produtor publica uma vez e não sabe quem ouve. Adicionar um quarto consumidor não toca o serviço de pedidos: basta assinar o tópico. É o desacoplamento que justifica a arquitetura.
- Por que fila entre o SNS e o consumidor. SNS sozinho entrega por push: se o consumidor está fora, a mensagem se perde. Com SQS no meio, ela espera. Este é o motivo do padrão, e é exatamente o que a prova testa.
- Cada consumidor no seu ritmo. O consumidor lento acumula na própria fila sem atrasar os outros. Sem as filas separadas, o mais lento vira o teto de todos.
- DLQ por fila isola o problema. Falha no consumidor de estoque enche a DLQ dele, e só. Faturamento e e-mail seguem normalmente — e você reprocessa a DLQ depois de corrigir.
- Quando trocar SNS por EventBridge. Se o roteamento depende do CONTEÚDO do evento — "pedido acima de R$ 10 mil vai para revisão" — a regra é do EventBridge. SNS entrega tudo a todos os assinantes do tópico, sem inspecionar o corpo.
Onde isso entra no exame
📘 Domain 1 — Development with AWS Services· 32%
O exame quer que você separe os três por mecânica: SQS quando o consumidor puxa e precisa de retentativa; SNS quando um evento vai para muitos assinantes agora; EventBridge quando há roteamento por conteúdo do evento ou origem SaaS. Visibility timeout menor que o tempo de processamento é a causa clássica de mensagem processada duas vezes.
Quiz rápido
Quando usar EventBridge em vez de SNS?
Fan-out pattern
💡
Publisher → SNS topic → múltiplas SQS subscribers. Cada consumer processa independente, retry/DLQ isolado. Padrão clássico pra compound effects em event (user signup → email + analytics + CRM sync, cada um em fila separada).
import boto3, json
sns = boto3.client("sns")
# SNS entrega para N assinantes. Sozinho, ele NÃO retém: se o consumidor está
# fora do ar, a mensagem se perde. Por isso cada consumidor fica atrás de uma SQS.
sns.publish(
TopicArn=TOPICO,
Message=json.dumps({"pedido_id": "4471", "valor": 250.0}),
MessageAttributes={
# Filtro por atributo: cada assinante recebe só o que lhe interessa,
# em vez de todos receberem tudo e descartarem no código.
"tipo": {"DataType": "String", "StringValue": "pedido.criado"},
},
)
# Do lado do consumidor, o que evita reprocessamento infinito é o par
# visibility timeout + fila de mensagens mortas.
sqs = boto3.client("sqs")
sqs.set_queue_attributes(QueueUrl=FILA, Attributes={
# Regra prática: 6x o tempo médio de processamento. Curto demais e outra
# cópia da mesma mensagem é entregue enquanto a primeira ainda roda.
"VisibilityTimeout": "180",
"RedrivePolicy": json.dumps({"deadLetterTargetArn": DLQ, "maxReceiveCount": 5}),
})Perguntas frequentes
❓ Como combinar tópico e fila no mesmo desenho?
Com o tópico publicando para várias filas — cada consumidor tem a própria fila e processa no próprio ritmo, sem afetar os outros. É o padrão de distribuição que resolve o problema de um consumidor lento atrasar todos. Assinar o tópico direto na função perde o amortecimento da fila.
❓ Quando o barramento de evento é melhor que tópico?
Quando há roteamento por conteúdo do evento, integração com muitos serviços por regra, ou necessidade de repetir evento arquivado. O tópico é mais simples e mais barato para distribuição pura. A palavra "regra" ou "filtrar por atributo do evento" no enunciado aponta para o barramento.
❓ O que é tempo de invisibilidade e por que ele importa?
É o período em que a mensagem fica escondida dos outros consumidores depois de ser recebida. Se o processamento demora mais que isso, a mensagem reaparece e é processada duas vezes — que é a causa mais comum de duplicata. O ajuste é o tempo real de processamento, com margem.
Fixando
Quiz rápido
Uma fila SQS tem mensagens sendo processadas repetidamente por consumidores diferentes. Qual é a causa provável?
Quiz rápido
Qual configuração garante que mensagens que falham repetidamente não fiquem em loop na fila?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…