RabbitMQ vs SQS/SNS: qual mensageria escolher
Roteador sofisticado que você opera ou primitivas gerenciadas da AWS: os 5 critérios que decidem, o padrão fan-out SNS+SQS e onde o Kafka entra (e não entra) na conversa.
Sua arquitetura decidiu conversar por eventos, e a primeira pergunta prática chegou: qual broker? O duelo mais comum no mercado brasileiro coloca de um lado o veterano RabbitMQ e do outro a dupla gerenciada da AWS (SQS + SNS). A boa notícia: a escolha fica óbvia quando se entende o que cada um é.
Dois modelos mentais diferentes
RabbitMQ é um roteador de mensagens sofisticado (rabbitmq.com). Produtores publicam em exchanges, que roteiam para filas segundo regras: chave exata, padrões com curinga (pedido.*.cancelado), cabeçalhos, broadcast. Prioridades, TTL por mensagem, confirmação fina, ordem por fila. É uma caixa de ferramentas completa de mensageria, que você opera: cluster, upgrades, monitoramento, dimensionamento.
SQS e SNS são primitivas gerenciadas (aws.amazon.com/sqs). SQS é uma fila durável e escalável: produtores enfileiram, consumidores puxam, mensagens processadas somem. SNS é pub/sub: publica-se num tópico, todos os assinantes recebem. Simples por design, e o padrão de mercado é combiná-los: SNS na frente (fan-out) com uma SQS por consumidor: cada serviço tem sua fila, com seu ritmo e sua DLQ (próximo artigo da série).
┌── SQS: estoque → serviço de estoque
PedidoConfirmado → SNS ─┼── SQS: fiscal → serviço fiscal
└── SQS: e-mails → serviço de notificação
Os critérios que decidem
1. Quem opera às 3h da manhã? A pergunta de sempre, e aqui ela pesa mais que tudo. SQS/SNS não têm servidor, patch, cluster nem disco para acabar: escala e durabilidade são problema da AWS. RabbitMQ autogerido exige competência real de operação (e o gerenciado, como o Amazon MQ, devolve parte da simplicidade cobrando por ela). Para a maioria dos times na AWS, SQS+SNS é o padrão sensato.
2. Complexidade de roteamento. Se o seu domínio pede roteamento rico (padrões por tópico, prioridades, TTL fino, retry customizado por tipo), o RabbitMQ entrega nativamente o que no SQS vira gambiarra de filtros e filas. Workflows internos complexos são o habitat dele.
3. Portabilidade. RabbitMQ fala AMQP (padrão aberto) e roda em qualquer lugar: on-premise, qualquer nuvem, seu cluster K8s. SQS/SNS são AWS. Se multi-ambiente é requisito real (não teórico), pesa.
4. Latência e throughput. RabbitMQ entrega latências sub-milissegundo em rede local; SQS opera na casa de milissegundos-a-dezenas com escala infinita horizontal. Para 99% dos casos de negócio, ambos sobram; benchmarks só decidem nos extremos.
5. Custo. SQS cobra por requisição (com um free tier generoso: o primeiro milhão/mês); RabbitMQ cobra em infraestrutura + gente para operar. Em volume moderado, o gerenciado quase sempre ganha na conta completa.
E o Kafka? (a pergunta inevitável)
Kafka resolve outro problema: não é uma fila, é um log de eventos persistente e re-lível: os consumidores leem no seu ritmo, podem reprocessar o histórico, e o mesmo evento serve análise, integração e auditoria. Se a sua necessidade é "distribuir tarefas e integrar serviços", fila basta e Kafka é complexidade a mais. Se é "fluxo contínuo de eventos como fonte de verdade re-processável", aí é a categoria dele.
O checklist de implantação (para qualquer escolha)
- Idempotência no consumidor: toda mensageria séria entrega "pelo menos uma vez"; duplicatas vão acontecer (é o terceiro artigo desta série).
- DLQ configurada desde o dia um: mensagem envenenada sem fila de quarentena trava o mundo (próximo artigo).
- Visibilidade: profundidade da fila, idade da mensagem mais velha e taxa de erro com alertas.
- Contratos versionados: o schema do evento é API pública, como sempre.
O resumo honesto
- Time na AWS, casos padrão de fila e fan-out: SNS + SQS, sem drama.
- Roteamento sofisticado, multi-ambiente, workflows internos ricos: RabbitMQ, com operação levada a sério.
- Fluxo de eventos como fonte de verdade: a conversa é Kafka, e é outra conversa.
Escolher e implantar essa espinha dorsal (com DLQs, idempotência e observabilidade desde o início) é parte do nosso serviço de Arquitetura de Software.
Descreva sua integração mais frágil para a IA da Rabelo Digital, aqui no canto da tela, e ela indica qual primitiva de mensageria resolve. Sem formulário, sem espera.
Deixe um Comentário