SNS vs SQS vs Kinesis: Pare de Adivinhar, Comece a Escolher

SNS vs SQS vs Kinesis: Pare de Adivinhar, Comece a Escolher

Vou ser honesto: da primeira vez que precisei escolher entre SNS e SQS, fiquei 40 minutos olhando pro console da AWS, abri sete abas e mesmo assim fiquei na dúvida. Isso foi há uns anos. Hoje a AWS tem *seis* — sim, seis — serviços diferentes de entrega de eventos. Até arquiteto sênior se perde.

O segredo é que não é um problema difícil. Basta parar de pensar nos serviços e começar a pensar no *formato* do dado. Você precisa de push ou pull? Replay? Fan-out? Roteamento por conteúdo? Aí está a decisão de verdade.

Vou explicar com o framework que eu gostaria de ter tido na época.

Os Concorrentes (Um Resumo Rápido e Opinativo)

SNS — O Mega-fone
O SNS (Simple Notification Service, https://aws.amazon.com/sns/) é pub/sub com push. Você publica uma mensagem e o SNS empurra ela pra todo assinante na hora — funções Lambda, filas SQS, endpoints HTTP, email, até push mobile. É fire-and-forget por design: o SNS não guarda mensagens e mal tenta reenviar. Se ninguém tá ouvindo, a mensagem some.

**Use quando:** um evento deve disparar várias ações ao mesmo tempo.

SQS — A Fila Confiável
O SQS (https://aws.amazon.com/sqs/) é fila baseada em pull. Produtores jogam mensagens lá, consumidores fazem polling e processam no próprio ritmo. Não é pub/sub — é ponto a ponto. Mensagens vivem até 14 dias, e filas FIFO dão ordenação estrita e processamento exactly-once.

**Use quando:** você tá desacoplando um produtor de um consumidor e precisa de confiabilidade sem roteamento complexo.

Kinesis — A Fita do Tempo
O Kinesis (https://aws.amazon.com/kinesis/) é plataforma de streaming de dados. Diferente do SQS, onde a mensagem é consumida e apagada, o Kinesis deixa múltiplos consumidores lerem o mesmo stream independentemente e fazerem replay por até 365 dias. Ordenação sólida por shard e throughput massivo.

**Use quando:** você tem dados de streaming em alto volume e precisa de replay.

MSK — Kafka Sem a Dor de Cabeça (Bom, Menos Delas)
O MSK (Managed Streaming for Apache Kafka, https://aws.amazon.com/msk/) é Kafka gerenciado. Você ganha o ecossistema completo — tópicos, partições, consumer groups, Kafka Connect, ksqlDB — sem montar o cluster. Mas ainda cuida do dimensionamento de brokers, tuning e patch de SO.

**Use quando:** seu time já sabe Kafka, precisa do Kafka Connect, ou tá migrando um Kafka existente.

EventBridge — O Roteador Inteligente
O EventBridge (https://aws.amazon.com/eventbridge/) é o novato que cresceu rápido. É um event bus com filtro e roteamento baseados em conteúdo poderosos. Você não só publica e reza — pode filtrar, transformar e rotear eventos pra targets diferentes dependendo do conteúdo. Também cuida de eventos agendados (um cron embutido) e integra nativamente com 140+ serviços da AWS.

**Use quando:** a lógica de roteamento depende do conteúdo do evento, ou você tá construindo uma arquitetura event-driven séria.

RabbitMQ — O Veterano de Guerra
O RabbitMQ (https://www.rabbitmq.com/) é o broker open-source com mais de uma década. Suporta múltiplos protocolos (AMQP, MQTT, STOMP), oferece roteamento flexível com exchanges e bindings, e roda em qualquer lugar. Na AWS, você roda tipicamente no EC2 (https://aws.amazon.com/ec2/) ou usa serviço gerenciado de terceiros.

**Use quando:** precisa de padrões de roteamento complexos tipo topic exchanges com wildcards, ou suporte multi-protocolo.

A Matriz de Decisão (Sua Cola)

Pare de comparar tabelas de features. Faça estas seis perguntas:

| Pergunta | Melhor Escolha |
|---|---|
| Desacoplamento um-para-um? | SQS |
| Fan-out um-para-muitos? | SNS ou EventBridge |
| Múltiplos consumidores independentes? | Kinesis |
| Já domina Kafka ou precisa do ecossistema? | MSK |
| Roteamento baseado no conteúdo da mensagem? | EventBridge |
| Roteamento complexo/existente + muitos protocolos? | RabbitMQ |

Minha filosofia: **padrão nos serviços nativos da AWS, a não ser que tenha motivo pra não usar.** Gerenciar seu próprio broker é toil operacional que você não precisa em 2026.

Cenários do Mundo Real

Cenário 1: Pipeline de Pedidos de E-commerce

Você tem uma loja online. Quando um pedido chega, precisa enviar email de confirmação, atualizar estoque, disparar envio e notificar antifraude.

Fan-out clássico. Minha escolha: **SNS ou EventBridge**. Publica um evento "order.placed" e o SNS empurra pro Lambda de email, pra fila SQS de estoque e pro serviço de envio simultaneamente. Mas se quiser filtro (tipo *só* notificar antifraude pra pedidos acima de $100), as rules baseadas em conteúdo do EventBridge ganham. Consumidores ficam mais simples — recebem só o que devem.

Cenário 2: Analytics de Clickstream

Sua plataforma recebe milhões de cliques por hora, e três times — analytics, ML e segurança — precisam consumir esses dados independentemente. Cada time quer replay por pelo menos uma semana.

Isso é território do **Kinesis**. Com SQS, um consumidor lendo a mensagem significa que ela sumiu pra todo mundo. Kinesis Data Streams deixa três consumidores independentes lerem o mesmo stream ao mesmo tempo, cada um no seu ritmo. Se seu time de analytics já fala Kafka, MSK é alternativa justa — mas Kinesis exige menos cuidado operacional.

Cenário 3: Sistema Legado Com Roteamento Complexo

Você tá modernizando um PDV antigo que usa RabbitMQ com topic exchanges tipo `order.created.retail` e `warehouse.stock.low`. Centenas de routing keys ligadas a serviços de backend.

Levar essa lógica pro SNS seria brutal — o SNS só suporta filtros básicos de subscription, não padrões complexos. **RabbitMQ** ou **EventBridge** funcionam. EventBridge te dá integração nativa AWS e schema registry, mas reescrever todas aquelas regras de roteamento leva tempo. Manter RabbitMQ significa menos esforço de migração, mas te deixa gerenciando instâncias EC2 pro futuro próximo. Eu escolheria EventBridge só se o time tivesse bandwidth; caso contrário, roda RabbitMQ e foca nos peixes maiores.

Dicas Práticas de Quem Já Apagou Incêndio

1. **Comece com SQS + Lambda.** É o padrão assíncrono mais simples na AWS. Resolve 90% das necessidades de desacoplamento de backend. Adicione SNS quando precisar de fan-out, EventBridge quando precisar de roteamento esperto.

2. **Pense em replay desde o dia um.** A pergunta difícil não é "meu serviço aguenta uma mensagem que falhou?" É "meu serviço aguenta *relER a mesma mensagem duas vezes*?" Kinesis e MSK tornam replays naturais. SQS FIFO te dá exactly-once mas limita throughput.

3. **Respeite os limites de retenção.** SNS não guarda nada. SQS teta em 14 dias. Kinesis chega a 365 dias com extended retention. MSK default é 7 dias (configurável pra mais). Se precisa de trilha de auditoria ou reprocessamento, escolha accordingly.

4. **Use long polling no SQS.** Ele acumula 20 segundos de mensagens em vez de ficar pollando filas vazias direto. Essa mudança sozinha pode cortar sua conta de SQS em 90%.

5. **Evite a pia da cozinha.** Já vi Lambda disparar tópico SNS, que publica pra fila SQS, que empurra pra outro Lambda, que joga no Kinesis — pra um upload de arquivo simples. Cada salto adiciona latência e um novo modo de falha. Só porque você *pode* encadear tudo não quer dizer que *deve*.

FAQ

Dá pra usar SNS e SQS juntos?
Com certeza — e é um dos padrões mais poderosos na AWS. SNS faz fan-out pra múltiplas filas SQS, e cada fila é processada independentemente por serviços diferentes. Junta o poder de fan-out do SNS com a confiabilidade, retenção e retries do SQS. Esse é o padrão por trás da maioria das arquiteturas event-driven sérias na AWS.

EventBridge tá substituindo o SNS?
Não totalmente, mas tá chegando perto. EventBridge faz tudo que o SNS faz — pub/sub, fan-out — mais filtro por conteúdo, descoberta de schema e integração profunda com AWS. Pra projetos novos, eu default no EventBridge. Mas se o caso de uso é push simples pra Lambda, SNS ainda é mais simples de entender e operar.

Quando escolher MSK em vez de Kinesis?
Escolha MSK quando seu time já conhece Kafka, quando precisa de Kafka Connect ou ksqlDB, ou quando tá migrando infra Kafka existente. Kinesis ganha quando você tá começando do zero, quer menos overhead operacional, e não precisa do ecossistema do Kafka.

RabbitMQ morreu no mundo AWS?
Não, mas virou nicho. Brilha pra lógica de roteamento complexa e suporte multi-protocolo. Muita enterprise ainda roda RabbitMQ em produção. Mas se você tá fazendo greenfield na AWS, eu prefiro fortemente EventBridge ou Kinesis. Gerencia a migração uma vez e agradece a si mesmo depois.

Considerações Finais

O "melhor" serviço de mensageria não é o que tem mais features. É o que casa com o formato do seu problema: SQS pra desacoplamento simples. SNS pra fan-out. Kinesis pra streaming com replay. MSK pra Kafka em escala. EventBridge pra roteamento inteligente. RabbitMQ pra complexidade old-school.

Agora você tem uma matriz mental de decisão que teria me poupado 40 minutos e sete abas naquele primeiro dia. Vai lá e constrói algo.