Message Queues: Kafka, RabbitMQ e SQS na Prática

Imagine um restaurante onde o cozinheiro e o garçom precisam ficar parados um na frente do outro para passar cada pedido. O caos seria imediato. No mundo do software, as Message Queues são os "post-its" que permitem que seu sistema respire e escale sem travar.

Em vez de um serviço "gritar" diretamente com outro (e morrer se não receber uma resposta rápida), ele deixa um recado em uma fila resiliente. Neste artigo, vamos colocar frente a frente gigantes como Kafka, RabbitMQ e SQS para descobrir qual deles é o maestro ideal para a orquestra assíncrona da sua aplicação.

1. Por Que Usar Message Queues

1.1 Desacoplamento

Sem filas, serviço A chama serviço B diretamente. Se B está lento ou indisponível, A também fica afetado. Com uma fila no meio, A apenas envia mensagens para a fila e continua. B consome no seu próprio tempo. Os serviços não precisam estar disponíveis simultaneamente, e um não precisa saber detalhes de implementação do outro.

Esse desacoplamento facilita mudanças: você pode substituir ou escalar B sem alterar A. Adicionar um terceiro consumidor C (talvez para analytics) não requer mudanças em A. A arquitetura se torna mais flexível e evoluível.

1.2 Buffering e Picos de Carga

Filas funcionam como buffers que absorvem picos de tráfego. Se seu sistema recebe 10x mais requisições que o normal por alguns minutos, uma abordagem síncrona pode derrubar os servidores downstream. Com uma fila, as mensagens se acumulam e são processadas no ritmo que os consumidores suportam. O pico é "aplainado" ao longo do tempo.

Isso é especialmente valioso para operações que podem esperar (enviar emails, processar relatórios, sincronizar com sistemas externos). A experiência do usuário no sistema principal não é afetada por lentidão em sistemas secundários.

1.3 Resiliência

Se um consumidor falha no meio do processamento, a maioria das filas pode reenviar a mensagem (dependendo da configuração). Messages não são perdidas só porque um servidor crashou. Comparado com chamadas HTTP síncronas, onde uma falha significa dado perdido a menos que você implemente retry complexo, filas oferecem durabilidade embutida.

2. Apache Kafka: Event Streaming de Alta Performance

2.1 O Que É Kafka

Kafka foi desenvolvido pelo LinkedIn e open-sourced em 2011. Não é exatamente uma "fila" no sentido tradicional — é uma plataforma de streaming de eventos. A diferença fundamental: mensagens em Kafka são persistidas em um log ordenado e podem ser relidas a qualquer momento. Filas tradicionais removem mensagens após consumo; Kafka as mantém por tempo configurável (dias, semanas, indefinidamente).

Isso permite casos de uso que filas tradicionais não suportam: replay de eventos (reprocessar histórico quando você corrige um bug), múltiplos consumidores lendo a mesma stream, e preservação de ordem estrita dentro de uma partição.

2.2 Quando Usar Kafka

Kafka brilha especialmente em cenários de alto throughput (milhares ou milhões de mensagens por segundo) e quando você precisa de um log de eventos durável e imutável para fins de replay, auditoria ou análise histórica. Sua arquitetura baseada em log-commit permite que você reconstrua o estado de um sistema inteiro a partir do log, o que é essencial para sistemas de event sourcing.

Exemplos típicos de uso incluem: ingestão de dados de IoT (sensores, dispositivos conectados) ou clickstream de websites (milhões de eventos por segundo); pipelines de dados que conectam sistemas analíticos como Hadoop, Spark ou sistemas de business intelligence; arquiteturas baseadas em event sourcing, onde o log de eventos é a fonte definitiva de verdade; replicação de dados entre data centers ou regiões para fins de backup, recuperação de desastres ou processamento em múltiplas localizações; e plataformas de streaming de dados em tempo real que exigem processamento contínuo de grandes volumes de informações, como sistemas de detecção de fraudes ou análise de comportamento do usuário.

2.3 Quando Não Usar Kafka

Kafka tem overhead operacional significativo. Gerenciar um cluster Kafka requer expertise. Para casos simples (alguns milhares de mensagens por dia, sem necessidade de replay), Kafka é overbearing. A latência de entrega é tipicamente maior que filas tradicionais — Kafka prioriza throughput e durabilidade sobre latência mínima. Se você precisa de respostas em microssegundos, Kafka não é ideal.

3. RabbitMQ: Message Broker Flexível

3.1 O Que É RabbitMQ

RabbitMQ é um message broker que implementa o protocolo AMQP (Advanced Message Queuing Protocol). Diferente de Kafka, RabbitMQ é uma fila tradicional: mensagens são entregues aos consumidores e tipicamente removidas após confirmação (acknowledge). RabbitMQ oferece flexibilidade extrema em roteamento: exchanges, bindings, routing keys permitem padrões complexos de distribuição de mensagens.

3.2 Quando Usar RabbitMQ

RabbitMQ é excelente para workloads tradicionais de filas: tarefas background (enviar emails, gerar PDFs), comunicação entre serviços com roteamento complexo, cenários onde latência baixa importa. A flexibilidade de roteamento permite padrões como pub/sub, topic-based routing, e RPC assíncrono. RabbitMQ também tem suporte a protocolos além de AMQP (MQTT para IoT, STOMP).

3.3 Quando Não Usar RabbitMQ

RabbitMQ não mantém histórico de mensagens consumidas — uma vez entregue e confirmado, a mensagem desaparece. Se você precisa de replay ou múltiplos consumidores lendo histórico, Kafka é melhor escolha. Para throughput extremo (milhões de mensagens por segundo), Kafka escala melhor. Clusters RabbitMQ têm limitações de escalabilidade horizontal que Kafka não tem.

4. Amazon SQS: Simplicidade Gerenciada

4.1 O Que É SQS

SQS (Simple Queue Service) é o serviço de filas gerenciado da AWS. "Gerenciado" significa que você não administra servidores: cria uma fila, envia mensagens, consome mensagens. A escalabilidade é automática. Existem dois tipos: Standard (ordem não garantida, at-least-once delivery) e FIFO (ordem garantida, exactly-once processing).

4.2 Quando Usar SQS

SQS é ideal quando você quer simplicidade e já usa AWS. Não há infraestrutura para gerenciar, não há upgrades, não há preocupação com capacidade. O preço é por uso (pay-per-message), sem custos fixos. Para startups e times pequenos sem expertise em operações de Kafka ou RabbitMQ, SQS reduz drasticamente a carga operacional.

SQS Standard oferece throughput praticamente ilimitado. FIFO tem limite de 300 transações por segundo (ou 3.000 com batching), suficiente para muitos casos de uso.

4.3 Quando Não Usar SQS

SQS é AWS-only — vendor lock-in é real. Se você quer multi-cloud ou on-premises, RabbitMQ ou Kafka são melhores escolhas. SQS não oferece features avançadas como roteamento complexo (RabbitMQ) ou log persistente com replay (Kafka). Latência é razoável (dezenas a centenas de milissegundos) mas não é a mais baixa entre as opções.

5. Comparação Resumida

6. Padrões de Uso e Boas Práticas

6.1 Idempotência

Mensagens podem ser entregues mais de uma vez em muitos sistemas. Seus consumidores devem ser idempotentes: processar a mesma mensagem duas vezes deve ter o mesmo resultado que processar uma vez. Isso tipicamente envolve usar IDs únicos e verificar se o processamento já foi feito.

6.2 Dead Letter Queues

Quando uma mensagem falha repetidamente, ela deve ir para uma "dead letter queue" em vez de bloquear o processamento ou ser perdida. Isso permite investigação posterior e evita que mensagens problemáticas causem loops infinitos.

6.3 Monitoramento

Monitore métricas cruciais: tamanho da fila (acumulando?), latência de processamento (aumentando?), taxa de erros (mensagens para DLQ?). Alertas em thresholds permitem intervir antes que problemas afetem usuários.

7. Conclusão

As filas de mensagens são a espinha dorsal de qualquer arquitetura distribuída que pretenda ser robusta. Kafka, RabbitMQ e SQS não são concorrentes diretos no sentido de que um "substitui" o outro; eles são ferramentas diferentes para problemas diferentes. O pior erro que um arquiteto pode cometer é não usar filas quando o acoplamento se torna perigoso, ou tentar forçar o Kafka para um problema que um simples SQS resolveria com um clique.

Entender seus requisitos de throughput, latência e durabilidade é o primeiro passo. E lembre-se: não há nada de errado em usar mais de uma dessas ferramentas em um mesmo sistema. No fim do dia, o que importa é que suas mensagens cheguem ao destino e que sua infraestrutura aguente o tranco, não importa o tamanho da carga.

---

8. Apêndice A: Glossário de Termos

• AMQP: Advanced Message Queuing Protocol, protocolo padrão para message brokers.
• At-Least-Once Delivery: Garantia de que mensagens são entregues pelo menos uma vez (podem duplicar).
• At-Most-Once Delivery: Mensagens entregues no máximo uma vez (podem ser perdidas).
• Broker: Servidor que gerencia filas e roteamento de mensagens.
• Consumer: Aplicação que lê mensagens de uma fila.
• Dead Letter Queue (DLQ): Fila para mensagens que falharam processamento.
• Exactly-Once: Garantia de processamento exatamente uma vez (difícil de implementar).
• Exchange (RabbitMQ): Componente que roteia mensagens para filas.
• Idempotência: Propriedade onde múltiplas execuções têm mesmo resultado que uma.
• Offset (Kafka): Posição de uma mensagem no log.
• Partition (Kafka): Subdivisão de um topic para paralelismo.
• Producer: Aplicação que envia mensagens para uma fila.
• Topic (Kafka): Categoria ou canal de mensagens.
• Visibility Timeout (SQS): Tempo que mensagem fica invisível enquanto sendo processada.

9. Apêndice B: Referências

• Apache Kafka Documentation. kafka.apache.org/documentation.
• RabbitMQ Documentation. rabbitmq.com/documentation.html.
• AWS SQS Documentation. docs.aws.amazon.com/sqs.
• Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly.
• Narkhede, N., Shapira, G., & Palino, T. (2017). Kafka: The Definitive Guide. O'Reilly.
• Videla, A., & Williams, J. J. (2012). RabbitMQ in Action. Manning.
• Newman, S. (2015). Building Microservices. O'Reilly.

Este artigo foi desenvolvido com base em documentação técnica e experiência prática da indústria.