Task queues, pub/sub fan-out, event streaming e request-reply são problemas distintos. Escolher a ferramenta pelo nome antes de definir o problema gera custo de migração e conta mensal inflada. Kafka, RabbitMQ e SQS resolvem cada um deles de forma diferente.
Kafka: log distribuído com replay
O Kafka guarda eventos num log distribuído que consumidores podem reler desde o início. Consumer groups escalam ao somar membros. O throughput chega a centenas de milhares de mensagens por segundo em clusters modestos. A operação consome dedicação: brokers, partições, rebalances e retenção exigem atenção mesmo no MSK ou Confluent. Use Kafka para event sourcing, pipelines de analytics e broadcast para múltiplos consumidores independentes.
RabbitMQ: broker com roteamento rico
O RabbitMQ filtra por padrão de chave em topic exchanges, captura mensagens rejeitadas em dead-letter exchanges, reordena entregas por prioridade e replica estado entre nós com quorum queues. Cobre dezenas de milhares de mensagens por segundo com folga e resolve filas de tarefas com topologia complexa usando menos peças que um cluster Kafka.
SQS: fila gerenciada dentro da AWS
O SQS cobra por mensagem e escala sozinho. Limites: 256KB por mensagem, delay máximo de 15 minutos, preço na faixa de centavos por milhão de requisições. Filas FIFO adicionam ordenação estrita com tetos de throughput (300 req/s por padrão, até 3.000 com batching). Equipes AWS-native ganham infraestrutura de fila sem administrar servidores.
Ordenação por partição
O Kafka garante ordem dentro de cada partição. A chave de partição decide a sequência: pedidos particionados por customer_id preservam ordem por cliente. O RabbitMQ também abandona ordenação global sob consumers concorrentes. Projete consumidores idempotentes em qualquer ferramenta. Infraestrutura otimiza, idempotência corrige.
Custo operacional
- Kafka gerenciado (MSK, Confluent): cluster mínimo a partir de ~$200/mês
- RabbitMQ self-hosted: instância barata, mas HA, failover e upgrades caem no seu backlog
- SQS: preço por mensagem, escala a zero quando o tráfego some
Ponto de partida
Comece com SQS se o time vive na AWS, ou RabbitMQ se roteamento rico importa fora dela. Migre para Kafka quando replay de histórico, múltiplos consumidores independentes ou 100k+ msg/s virarem requisito real. Time pequeno com fila de jobs precisa de fila confiável e observabilidade decente, não de cluster próprio.
Curtiu o conteúdo?
Construo produtos web e soluções com IA do jeito certo — arquitetura sólida, código sustentável e entrega real.
Vamos conversar