Kafka é fila ou log?
Uma fila tradicional costuma remover a mensagem conforme ela é consumida. Em Kafka, eventos são gravados em tópicos e retidos por tempo ou política configurada. Consumidores acompanham posições (offsets) e podem reler eventos enquanto ainda estiverem disponíveis. Isso favorece integração entre produtores e vários consumidores, replay e pipelines de dados.
Persistência e retenção não significam arquivamento eterno: capacidade, política de retenção e replicação precisam ser projetadas e monitoradas.
Tópicos, partições e ordem
Um tópico é dividido em partições para distribuir armazenamento e processamento. Cada partição é um log ordenado; a ordem total do tópico não é garantida entre partições. Se a ordem por pedido importa, use uma chave estável, como orderId, para que eventos daquele pedido sejam encaminhados à mesma partição.
Partições permitem paralelismo, mas uma partição só pode ser atribuída a um consumidor de um mesmo consumer group por vez. Aumentar a quantidade pode afetar distribuição, estado e operação; escolher uma chave desigual pode criar partições quentes.
Consumer groups e offsets
Consumidores do mesmo grupo dividem as partições para escalar uma tarefa. Grupos diferentes leem independentemente o mesmo tópico: analytics e notificações, por exemplo, mantêm seus próprios offsets. Se um consumidor falha, partições podem ser reassociadas e o processamento pode retomar de uma posição anterior.
O momento de confirmar offset é uma decisão de consistência. Confirmar antes de concluir o efeito pode perder trabalho após uma falha; confirmar depois pode repetir a mensagem. Em geral, desenhe consumidores idempotentes e trate reprocessamento como parte do sistema, não como exceção improvável.
Entrega e processamento sem promessas mágicas
Produtores podem usar confirmações e políticas de retry para aumentar confiabilidade de publicação. Kafka oferece recursos de transações para certos fluxos Kafka-a-Kafka; isso não cria uma transação atômica entre o tópico, um banco relacional e uma API externa. “Exactly once” depende do escopo e da configuração: não garante por si só que um efeito externo nunca se repita.
Se uma alteração de banco precisa publicar um evento, o padrão Transactional Outbox fecha a janela entre gravação local e publicação, enquanto o consumidor ainda deve lidar com duplicatas.
Quando Kafka faz sentido — e quando pesa
Considere Kafka quando há alto volume de eventos, múltiplos consumidores independentes, retenção e replay, streaming ou integração de dados. Pode ser exagero para uma fila de tarefas simples de uma aplicação: clusters, partições, esquemas, retenção, monitoramento e capacidade operacional têm custo.
Compare com RabbitMQ, que oferece roteamento de mensagens e filas tradicionais, e Azure Service Bus, serviço gerenciado de mensageria na nuvem Azure. A escolha depende do padrão de consumo e do ambiente, não de uma classificação absoluta.
Operação e observabilidade
Acompanhe lag por consumer group, taxa de produção e consumo, partições subutilizadas ou quentes, erros de serialização, rebalances e uso de disco. Um consumidor saudável no processo pode ainda estar atrasado em relação à produção. Veja observabilidade e resiliência para completar o desenho operacional.