Escolher um message broker adequado é uma das decisões de arquitetura que mais impacta a escalabilidade, a resiliência e o custo operacional de um sistema distribuído. Times de engenharia frequentemente comparam Kafka, RabbitMQ e Amazon SQS sem entender profundamente as diferenças de modelo de entrega, persistência e semântica de consumo — e isso gera retrabalho caro em produção.
Neste artigo, vamos analisar tecnicamente cada opção de message broker, destacando arquitetura interna, prós, contras e cenários reais de uso. O objetivo é dar a você, líder técnico ou founder de SaaS, critérios objetivos para decidir — sem depender de hype de mercado.
O que é um message broker e por que ele importa na arquitetura
Um message broker é um componente de infraestrutura responsável por intermediar a comunicação assíncrona entre serviços, desacoplando produtores e consumidores de mensagens. Em arquiteturas de microsserviços, ele resolve problemas como back-pressure, retry, ordenação de eventos e tolerância a falhas de rede.
Existem duas famílias principais de message broker: os baseados em fila tradicional (como RabbitMQ e SQS) e os baseados em log distribuído (como Kafka). Essa distinção arquitetural é o que define throughput, latência, retenção de dados e complexidade operacional de cada solução.
Kafka: arquitetura de log distribuído para alto throughput
O Apache Kafka opera como um log distribuído particionado, persistido em disco e replicado entre brokers. Cada tópico é dividido em partições, e consumidores leem mensagens de forma sequencial via offset, o que permite reprocessamento e múltiplos grupos de consumo independentes sobre o mesmo dado.
- Prós: altíssimo throughput, retenção configurável de mensagens (permitindo replay), forte adoção em pipelines de streaming e event sourcing.
- Contras: complexidade operacional elevada (gestão de partições, rebalanceamento de consumer groups, tuning de ZooKeeper ou KRaft), curva de aprendizado maior para times pequenos.
- Casos de uso: pipelines de dados em tempo real, agregação de logs, arquiteturas orientadas a eventos com múltiplos consumidores do mesmo stream.
bin/kafka-topics.sh --create --topic pedidos \n --partitions 6 --replication-factor 3 \n --bootstrap-server broker:9092RabbitMQ: broker tradicional com roteamento flexível
O RabbitMQ implementa o protocolo AMQP 0-9-1 e utiliza um modelo de exchanges e filas com roteamento configurável (direct, topic, fanout, headers). Diferente do Kafka, a mensagem é removida da fila após confirmação de consumo (ack), não sendo pensado nativamente para replay de longo prazo.
- Prós: roteamento sofisticado, baixa latência para cargas moderadas, ecossistema maduro de plugins (delayed messages, shovel, federation), boa documentação.
- Contras: throughput inferior ao Kafka em cenários de altíssimo volume, escalonamento horizontal mais trabalhoso que arquiteturas de log distribuído.
- Casos de uso: filas de tarefas assíncronas, comunicação entre microsserviços com necessidade de roteamento condicional, sistemas de notificação.
Amazon SQS: simplicidade serverless para filas gerenciadas
O SQS é um serviço de fila totalmente gerenciado pela AWS, oferecido em dois modelos: Standard (entrega best-effort, alta escala, possível duplicidade) e FIFO (ordenação garantida, throughput mais limitado). Não há necessidade de provisionar ou operar brokers — a AWS cuida de toda a infraestrutura subjacente.
- Prós: zero overhead operacional, escalabilidade automática, integração nativa com Lambda, SNS e outros serviços do ecossistema AWS.
- Contras: menor controle sobre latência e comportamento interno, vendor lock-in, custo pode crescer significativamente em altos volumes de mensagens.
- Casos de uso: arquiteturas serverless, integrações desacopladas entre funções Lambda, times sem capacidade de manter infraestrutura própria.
Esse trade-off entre controle e simplicidade operacional é o mesmo que discutimos ao comparar Kubernetes gerenciado e serverless: quanto mais você delega ao provedor, menos flexibilidade arquitetural você mantém.
Trade-offs: qual message broker escolher para cada caso
Não existe um message broker universalmente superior — a escolha correta depende do volume de mensagens, da necessidade de replay, do orçamento de operação e da maturidade da equipe de TI.
- Se o requisito é streaming e replay de eventos, Kafka é a escolha técnica mais consistente, desde que haja capacidade de operação.
- Se o requisito é roteamento condicional e baixa complexidade operacional, RabbitMQ atende bem a maioria dos cenários corporativos.
- Se o requisito é time reduzido, arquitetura serverless e previsibilidade de manutenção, SQS costuma ser a opção mais pragmática.
Para founders de SaaS que também precisam equilibrar decisões técnicas com crescimento comercial, vale revisar as dicas de marketing digital para founders de SaaS, já que arquitetura sólida sustenta a promessa que o time comercial vende ao mercado.
Conclusão
Comparar tecnologias de message broker exige olhar além de benchmarks isolados: arquitetura interna, semântica de entrega e custo operacional determinam se Kafka, RabbitMQ ou SQS é a escolha certa para o seu contexto. Avalie o volume real, a necessidade de replay e a maturidade operacional do seu time antes de decidir — essa é a diferença entre uma stack que escala e uma que gera dívida técnica.
