Parte I — Fundamentos

O que é Apache Kafka?

Origem, contexto, o problema que o Kafka resolve e por que ele não é apenas uma fila.

Nesta página

Antes de entrar em Producer, Broker ou Partition, vale resolver uma pergunta que a maioria dos desenvolvedores nunca para para responder com precisão: por que o Kafka existe? Se você não consegue justificar a existência de uma peça de infraestrutura, também não consegue justificar quando usá-la — e é exatamente esse tipo de julgamento que uma entrevista sênior tenta medir.

O problema antes do Kafka

Em um sistema com poucos serviços, integração ponto a ponto funciona: o serviço de pagamentos chama diretamente o serviço de notificação via HTTP, que chama o serviço de antifraude, e assim por diante. O problema aparece quando o número de serviços cresce. Cada novo consumidor de um evento de pagamento significa uma nova chamada síncrona, um novo ponto de falha e um novo acoplamento direto entre times.

Imagine um evento de "pagamento aprovado" em um banco digital. Hoje ele pode interessar a: notificação push, antifraude, cashback, contabilidade, analytics e atualização de limite de crédito. Se o serviço de pagamentos chamar cada um desses via HTTP síncrono, ele passa a depender da disponibilidade de todos eles — e a adicionar um sétimo consumidor exige alterar o código do serviço de pagamentos novamente.

Não é só sobre performance

O problema central não é volume de requisições — é acoplamento. Um sistema em que o produtor de um evento precisa conhecer todos os seus consumidores não escala organizacionalmente, mesmo que escale em throughput.

Event streaming e arquitetura orientada a eventos

O Kafka nasceu no LinkedIn, por volta de 2010, para resolver o problema de mover grandes volumes de dados de atividade (cliques, visualizações, métricas) entre sistemas de forma confiável e desacoplada. A ideia central é simples de enunciar e profunda na prática: em vez de sistemas se chamando diretamente, eles publicam e consomem eventos através de um log distribuído compartilhado.

Event streaming

Event streaming é o padrão arquitetural em que fatos que já aconteceram ("pagamento aprovado", "boleto pago", "cartão bloqueado") são publicados como eventos imutáveis em um log central, e qualquer número de sistemas interessados pode consumi-los de forma independente, no seu próprio ritmo.

Isso é diferente de simplesmente "enviar uma mensagem". Um evento não é um comando ("processe este boleto"); é uma afirmação sobre algo que já ocorreu. O produtor não sabe — e não precisa saber — quem vai consumir o evento nem o que cada consumidor vai fazer com ele. Essa inversão é a base da arquitetura orientada a eventos (event-driven architecture): o sistema de pagamentos publica "pagamento aprovado" e segue em frente; antifraude, notificação e contabilidade descobrem esse fato de forma assíncrona, cada um na sua velocidade.

Kafka como log distribuído

Tecnicamente, o Kafka é implementado como um log distribuído, particionado e replicado. "Log" aqui não é log de aplicação — é a estrutura de dados: uma sequência ordenada e imutável de registros, cada um identificado por uma posição crescente (o offset). Novos eventos são sempre anexados ao final; nada é alterado in-place.

Producer publica no Topic; o Topic é dividido em Partitions; múltiplos Consumers leem de forma independente.

Essa estrutura de log é o que permite duas propriedades que fazem o Kafka ser fundamentalmente diferente de uma fila tradicional:

Múltiplos consumidores independentes podem ler o mesmo conjunto de eventos, cada um mantendo sua própria posição de leitura (offset), sem que a leitura de um afete a do outro.
Retenção configurável significa que o evento continua disponível no log depois de consumido — um novo serviço pode nascer amanhã e ler o histórico completo de "pagamento aprovado" dos últimos 7 dias sem que o sistema de pagamentos precise reenviar nada.

Kafka não é apenas uma fila

Essa é provavelmente a comparação mais repetida — e mais incompleta — sobre Kafka.

"Kafka é uma fila só que mais rápida"

Essa afirmação ignora a diferença estrutural mais importante: em uma fila clássica (RabbitMQ, SQS), uma mensagem consumida normalmente sai da fila — ela existe para ser entregue uma vez e desaparecer. No Kafka, consumir um evento não o remove do log; ele continua lá até a política de retenção expirá-lo, independentemente de quantos consumidores já o leram.

Uma fila modela trabalho a ser distribuído — cada item deve ser processado por exatamente um worker. O Kafka modela fatos a serem compartilhados — o mesmo evento pode (e geralmente deve) ser lido por vários sistemas diferentes, cada um com sua própria interpretação do fato. É possível usar Kafka para distribuir trabalho (é isso que um Consumer Group faz dentro de uma partition), mas reduzir o Kafka a isso é perder a metade do motivo pelo qual ele foi desenhado.

Quando utilizar

Múltiplos sistemas precisam reagir ao mesmo fato de negócio, de forma independente.
Você precisa de replay: reprocessar eventos antigos para corrigir um bug, popular um novo sistema ou reconstruir um estado (ex.: reindexar um Elasticsearch a partir do histórico de eventos).
O volume e a taxa de eventos são altos o suficiente para que acoplamento síncrono se torne um risco de disponibilidade (um serviço fora do ar não pode travar os demais).
Você quer desacoplar produtores de consumidores no nível organizacional — times diferentes evoluindo seus serviços sem coordenar deploys.

Quando não utilizar

Comunicação estritamente request/response, onde quem chama precisa de uma resposta imediata (ex.: autorizar uma transação de cartão em tempo real de ponta a ponta) — isso é papel de uma chamada síncrona (HTTP/gRPC), não de um evento assíncrono.
Sistemas pequenos, com poucos serviços e baixo volume, onde a complexidade operacional de um cluster Kafka não se paga. Uma fila simples ou até chamadas diretas resolvem com menos esforço.
Quando a equipe não tem — e não vai construir — a maturidade operacional mínima para lidar com um sistema distribuído com estado (monitoramento de lag, gestão de partições, upgrades de cluster).

Limitações

Kafka não garante ordenação global entre partitions — apenas dentro de uma mesma partition (voltamos a isso no Capítulo 4).
Não é um banco de dados transacional; embora suporte transações (Capítulo 12), ele não substitui um banco relacional para consultas ad-hoc sobre o estado atual.
Tem uma curva operacional real: partições mal dimensionadas, rebalances mal compreendidos e retenção mal configurada são causas comuns de incidentes em produção.

Como aparece em entrevistas

Praticamente toda entrevista sobre Kafka começa com uma variação de "o que é Kafka" ou "por que usar Kafka em vez de uma fila". O entrevistador não quer a definição de dicionário — quer ver se você entende o problema de acoplamento que motivou a criação da ferramenta e se você sabe diferenciar "fila de trabalho" de "log de eventos compartilhado". Respostas que citam apenas "alta performance" ou "processa muitos dados" soam decoradas e raramente convencem.

Dica de entrevista

Estruture a resposta em três passos: (1) o problema — acoplamento entre produtores e múltiplos consumidores; (2) a solução — log distribuído e imutável, com múltiplos consumidores independentes; (3) a consequência — replay, desacoplamento organizacional e a diferença fundamental em relação a uma fila.

Relação com Java e Spring Boot

Na prática, um desenvolvedor Java interage com o Kafka através do client oficial (kafka-clients) ou, mais comumente, via Spring Kafka, que encapsula KafkaTemplate para produção e @KafkaListener para consumo (Capítulos 13 e 14). O conceito de "publicar um evento e seguir em frente" se traduz diretamente em código: um @Service de pagamentos publica um evento via KafkaTemplate.send(...) dentro (idealmente) da mesma transação que persiste o pagamento no banco, e retorna, sem esperar por antifraude, notificação ou contabilidade.

Como aparece em sistemas reais

PIX recebido, sem Kafka vs. com Kafka

Sem um log de eventos, o serviço que recebe a confirmação de um PIX precisaria chamar diretamente o serviço de saldo, o de notificação push, o de extrato e o de antifraude — de forma síncrona ou com uma fila dedicada para cada um. Com Kafka, ele publica um único evento PixRecebido em um tópico; saldo, notificação, extrato e antifraude consomem esse mesmo evento de forma independente, cada um no seu próprio Consumer Group, sem que o serviço de recebimento do PIX saiba que eles existem.

Resumo

Kafka resolve o problema de acoplamento entre um produtor de eventos e múltiplos consumidores independentes, através de um log distribuído, particionado e replicado, onde eventos são anexados e retidos por um período configurável — não removidos ao serem consumidos. Isso o torna estruturalmente diferente de uma fila tradicional, que modela distribuição de trabalho, não compartilhamento de fatos.

Pode vir a seguir

Depois de responder "o que é Kafka", prepare-se para: "Kafka é uma fila?", "quando você não usaria Kafka?" e "qual problema real você já resolveu com Kafka?".