Se você trabalha com sistemas que precisam trocar dados entre serviços, uma hora o nome Apache Kafka aparece. Ele virou quase sinônimo de “arquitetura de dados moderna”, e por isso mesmo carrega uma fama meio intimidadora. Muita gente ouve falar em broker, tópico, partição, consumer group e já pensa que é coisa de empresa gigante com time dedicado só pra cuidar disso. A verdade é mais simples do que parece, e depois de alguns anos rodando Kafka em produção eu posso dizer: a ideia central cabe em um parágrafo, o resto é detalhe de operação.

Neste post a gente vai do zero. Primeiro a definição direta, depois a arquitetura peça por peça (producer, broker, topic, partition, consumer), casos de uso que fazem sentido de verdade, quando você definitivamente não deveria usar Kafka, e uma comparação honesta com mensageria tradicional tipo RabbitMQ. No fim tem um FAQ com as dúvidas que mais aparecem. A ideia é que você termine a leitura sabendo não só o que é, mas se faz sentido pro seu caso.

O que é o Apache Kafka

Apache Kafka é uma plataforma distribuída de streaming de eventos que funciona como um log de mensagens durável, ordenado e replicado. Na prática, ele recebe fluxos de dados de várias fontes (chamadas de producers), guarda esses dados em disco de forma organizada e permite que vários sistemas (os consumers) leiam esse fluxo no ritmo que quiserem, sem interferir uns nos outros. É software livre, mantido pela Apache Software Foundation, e nasceu dentro do LinkedIn lá por 2011 pra resolver o problema de mover volumes gigantescos de eventos entre sistemas.

O jeito mais fácil de entender é pensar no Kafka como um gravador de fita que nunca para. Cada evento que chega é anexado ao final de um registro, e esse registro fica ali, guardado, disponível pra ser lido quantas vezes for preciso. Diferente de uma fila comum, onde a mensagem some depois que alguém consome, no Kafka o dado permanece pelo tempo que você configurar (horas, dias ou pra sempre). Isso muda completamente o que dá pra fazer com ele.

Por que o Kafka foi criado

Antes de existir uma ferramenta assim, empresas grandes tinham um problema chato: cada sistema precisava conversar com cada outro sistema. Se você tem o serviço de pedidos, o de estoque, o de faturamento, o de analytics e o de notificações, e todos precisam saber quando um pedido acontece, você acaba com uma teia de integrações ponto a ponto. Adiciona mais um sistema e a bagunça cresce de forma exponencial. Qualquer mudança vira um pesadelo.

O Kafka resolve isso invertendo a lógica. Em vez de cada sistema falar diretamente com os outros, todo mundo publica e lê de um ponto central. O serviço de pedidos escreve “pedido criado” no Kafka e não se importa com quem vai ler. Estoque, faturamento, analytics e notificações leem esse mesmo evento por conta própria. Adicionar um novo consumidor não afeta ninguém que já estava lá. Essa arquitetura desacoplada é o motivo real de tanta gente adotar Kafka, e é uma coisa que fila tradicional também faz, só que o Kafka faz em outra escala.

A arquitetura do Kafka peça por peça

Aqui está o coração do assunto. O Kafka tem poucos conceitos fundamentais, e depois que você entende como eles se encaixam, o resto fica natural. Vou passar por cada um na ordem em que um dado flui pelo sistema.

Producer: quem escreve os eventos

O producer é qualquer aplicação que envia dados pro Kafka. Pode ser um microserviço registrando cada clique de usuário, um sistema de pagamento avisando que uma transação foi aprovada, ou um sensor de IoT mandando leitura de temperatura. O producer decide pra qual tópico a mensagem vai e, opcionalmente, qual partição. Ele não espera resposta de ninguém que vai ler o dado, só confirma com o broker que a mensagem foi gravada. Isso é o que dá o desacoplamento: quem escreve não sabe nem se importa com quem lê.

Uma coisa que confunde iniciante é a chave da mensagem. Cada evento pode ter uma chave (a key), e o Kafka usa essa chave pra decidir a partição. Mensagens com a mesma chave sempre caem na mesma partição, o que garante que elas sejam lidas na ordem. Se você manda eventos de um mesmo usuário usando o ID dele como chave, todos os eventos daquele usuário ficam ordenados. Isso é importante e volta a aparecer daqui a pouco.

Broker: o servidor que guarda tudo

O broker é o servidor Kafka em si. Ele recebe as mensagens dos producers, grava em disco e entrega pros consumers. Um cluster Kafka normalmente tem vários brokers trabalhando juntos, e é aí que entra a resiliência. Os dados são replicados entre brokers, então se um servidor cai, outro assume com uma cópia idêntica e ninguém perde nada. Em produção você quase nunca roda um broker só, porque isso mataria o ponto de ter alta disponibilidade.

Cada broker é responsável por um pedaço dos dados. Quando você tem um tópico com várias partições espalhadas por vários brokers, a carga se distribui. É esse espalhamento que permite ao Kafka aguentar milhões de mensagens por segundo, coisa que um servidor único jamais faria sozinho.

Topic: a categoria dos eventos

O tópico é como você organiza os dados. Pense nele como uma categoria ou um nome de canal. Você pode ter um tópico chamado “pedidos”, outro chamado “pagamentos”, outro “logs-de-acesso”. Producers escrevem em tópicos, consumers leem de tópicos. É a unidade lógica de organização, e você cria quantos precisar de acordo com o tipo de evento que cada um carrega.

Um detalhe que costuma pegar gente de surpresa: no Kafka, ler uma mensagem não a apaga. Vários consumers diferentes podem ler o mesmo tópico de forma independente, cada um no seu ritmo. O tópico guarda os eventos pelo tempo de retenção que você definir, e cada consumer mantém o controle de onde parou. Isso é radicalmente diferente de uma fila comum, e é o que permite reprocessar dados históricos quando você precisa.

Partition: onde mora a escala e a ordem

Aqui está o conceito mais poderoso e o que mais gera dúvida. Cada tópico é dividido em partições, e cada partição é um log ordenado e imutável de mensagens. Quando um evento chega, ele é anexado ao final de uma partição e ganha um número sequencial chamado offset. É esse offset que o consumer usa pra saber até onde já leu.

As partições são o segredo da escalabilidade horizontal do Kafka. Um tópico com seis partições pode ser lido por até seis consumers em paralelo dentro de um mesmo grupo, cada um cuidando de uma partição. Quer processar mais rápido? Aumenta o número de partições e adiciona mais consumers. Só tem um porém importante: a ordem só é garantida dentro de uma partição, não no tópico inteiro. Por isso a chave da mensagem importa tanto. Se a ordem dos eventos de um usuário é crítica, você usa o ID dele como chave e o Kafka garante que todos vão pra mesma partição, na ordem certa.

Consumer e consumer group: quem lê os eventos

O consumer é a aplicação que lê os dados do Kafka. Ela se conecta a um ou mais tópicos e vai processando as mensagens conforme chegam ou reprocessando dados antigos, dependendo de onde você mandar ela começar. O consumer controla o próprio ritmo, e como o Kafka não apaga a mensagem depois da leitura, dá pra voltar no tempo e ler de novo se algo deu errado no processamento.

O conceito de consumer group é onde a mágica de escala acontece de verdade. Você agrupa vários consumers sob o mesmo group id, e o Kafka distribui as partições entre eles automaticamente. Se um consumer do grupo cai, o Kafka rebalanceia e passa as partições dele pros que sobraram, sem intervenção manual. E se você quer que dois sistemas totalmente diferentes leiam os mesmos dados, é só colocá-los em grupos diferentes: cada grupo recebe uma cópia completa do fluxo. Essa combinação de partição mais consumer group é o que faz o Kafka escalar de forma tão limpa.

Um producer e um consumer na prática

Teoria demais cansa. Vamos ver como isso fica em código de verdade. Abaixo tem um producer e um consumer simples em Python usando a biblioteca confluent-kafka, que é uma das mais usadas. Não é pseudocódigo, isso roda contra um Kafka de verdade com pequenas adaptações de configuração.

from confluent_kafka import Producer, Consumer

# --- Producer: envia um evento de pedido ---
producer = Producer({'bootstrap.servers': 'localhost:9092'})

def entregue(err, msg):
    if err:
        print(f'Falhou: {err}')
    else:
        print(f'Gravado em {msg.topic()} [partition {msg.partition()}]')

producer.produce(
    topic='pedidos',
    key='usuario-42',          # mesma key vai pra mesma particao
    value='{"pedido_id": 1001, "valor": 249.90}',
    callback=entregue
)
producer.flush()

# --- Consumer: le eventos do topico pedidos ---
consumer = Consumer({
    'bootstrap.servers': 'localhost:9092',
    'group.id': 'processador-de-pedidos',
    'auto.offset.reset': 'earliest'
})
consumer.subscribe(['pedidos'])

while True:
    msg = consumer.poll(1.0)
    if msg is None:
        continue
    if msg.error():
        print(f'Erro: {msg.error()}')
        continue
    print(f'Recebido: {msg.value().decode("utf-8")}')

Repare em três coisas. A key no producer garante ordenação por usuário. O group.id no consumer define o grupo que vai dividir as partições. E o auto.offset.reset como earliest diz pra começar do começo do tópico quando não há offset salvo, útil pra reprocessar tudo do zero. Trocar isso pra latest faz o consumer ler só os eventos novos. Esse tipo de ajuste é o que você mexe no dia a dia.

Casos de uso reais do Kafka

O Kafka não é uma ferramenta genérica que serve pra tudo. Ele brilha em cenários específicos, e é bom conhecê-los pra saber quando puxá-lo da caixa de ferramentas. Aqui vão os que eu vejo com mais frequência.

Pipelines de dados e integração de sistemas

Esse é o uso clássico, o motivo pelo qual ele foi criado. Mover dados de um lugar pro outro em tempo real, alimentando data warehouses, data lakes, sistemas de busca e o que mais precisar. Um evento acontece no sistema de origem, cai no Kafka, e vários destinos consomem sem que a origem precise saber quem são. Quando alguém fala em “backbone de dados da empresa”, geralmente é isso.

Processamento de eventos em tempo real

Detecção de fraude, monitoramento de métricas, recomendações que reagem ao que o usuário acabou de fazer. Tudo que precisa reagir a eventos no instante em que acontecem se encaixa bem. Combinado com ferramentas como Kafka Streams ou Apache Flink, dá pra fazer agregações, janelas de tempo e transformações no fluxo sem parar pra gravar em banco antes.

Log de atividades e auditoria

Como o Kafka guarda tudo em ordem e por tempo indeterminado se você quiser, ele é ótimo pra registrar um histórico imutável do que aconteceu no sistema. Cada ação vira um evento, e você tem uma trilha de auditoria completa que pode ser reprocessada. Isso alimenta desde compliance até reconstrução de estado em arquiteturas de event sourcing.

Comunicação entre microserviços

Em vez de microserviços se chamarem via HTTP síncrono e ficarem acoplados uns aos outros, eles se comunicam por eventos através do Kafka. O serviço A publica um evento, o serviço B reage quando puder. Se o B estiver fora do ar, os eventos ficam guardados no Kafka esperando ele voltar, e nada se perde. Esse padrão deixa o sistema muito mais tolerante a falha do que chamadas diretas.

Quando NÃO usar Kafka

Essa é a parte que quase ninguém fala, e é onde muita gente se enrola. Kafka é poderoso, mas ele traz complexidade operacional real. Rodar e manter um cluster saudável dá trabalho, e em vários casos ele é a ferramenta errada. Vou ser honesto sobre isso.

Se o seu volume de mensagens é baixo, tipo algumas centenas ou poucos milhares por dia, Kafka é overkill puro. Você vai gastar dias configurando e monitorando algo que uma fila simples resolveria em uma tarde. Nesses casos, RabbitMQ, Amazon SQS ou até uma tabela no banco de dados fazem o serviço com uma fração do esforço.

Kafka também não é um banco de dados. Se você precisa consultar dados por campos arbitrários, fazer joins ou buscar um registro específico rápido, use um banco de verdade. Kafka é ótimo pra ler sequências de eventos em ordem, péssimo pra “me dá o pedido número 8352 agora”. Tentar usá-lo como banco é receita pra frustração.

E se o que você precisa é um sistema de requisição e resposta, onde o cliente manda algo e espera uma resposta na hora, Kafka não foi feito pra isso. Ele é assíncrono por natureza. Forçar um padrão request-reply em cima dele funciona, mas é nadar contra a corrente. Uma API REST ou gRPC atende melhor. A regra prática que eu uso: se você não tem volume alto de eventos nem necessidade de que vários sistemas leiam o mesmo fluxo de forma independente, provavelmente não precisa de Kafka.

Kafka vs mensageria tradicional (RabbitMQ)

Essa comparação aparece em toda decisão de arquitetura, e a resposta honesta é que eles resolvem problemas diferentes, mesmo que na superfície pareçam a mesma coisa. RabbitMQ é um message broker tradicional, ótimo em roteamento inteligente e entrega de tarefas. Kafka é um log distribuído, ótimo em alto throughput e reprocessamento. A tabela abaixo resume as diferenças que mais pesam na hora de escolher.

Aspecto	Apache Kafka	RabbitMQ
Modelo	Log distribuído de eventos (streaming)	Fila de mensagens com broker inteligente
Retenção	Guarda mensagens por tempo configurável, mesmo após lidas	Mensagem some após ser consumida e confirmada
Throughput	Altíssimo (milhões de msg/s)	Alto, mas menor em escala extrema
Reprocessamento	Nativo, é só voltar o offset	Não foi feito pra isso
Roteamento	Simples, baseado em tópico e partição	Rico, com exchanges e routing keys flexíveis
Ordem	Garantida dentro da partição	Garantida na fila, mas frágil com múltiplos consumers
Caso ideal	Pipelines de dados, event sourcing, streaming	Filas de tarefas, RPC assíncrono, roteamento complexo

Na prática, a escolha costuma se resumir a uma pergunta: você precisa que o dado fique guardado e possa ser relido por vários sistemas, ou você precisa entregar uma tarefa pra alguém processar e esquecer? Se é a primeira, Kafka. Se é a segunda, RabbitMQ. E não é raro ver as duas ferramentas convivendo na mesma empresa, cada uma no que faz melhor.

Kafka é difícil de operar? Uma nota honesta

Vou ser direto porque isso importa na hora de decidir. Rodar Kafka em produção não é trivial. Você precisa pensar em replicação, em quantas partições cada tópico vai ter (mudar isso depois é chato), em monitoramento de lag dos consumers, em retenção de dados que não estoure o disco, e por muito tempo também no ZooKeeper, que era uma peça externa obrigatória. As versões mais novas trocaram o ZooKeeper pelo modo KRaft, que simplifica bastante essa parte, mas ainda assim é um sistema distribuído com suas manhas.

A boa notícia é que hoje existem serviços gerenciados que tiram esse peso das suas costas. Confluent Cloud, Amazon MSK e Aiven rodam o cluster pra você, e você foca só em producers e consumers. Se você está começando com Kafka e não tem um time de infra dedicado, começar por um serviço gerenciado é o caminho mais sensato. Deixa a complexidade operacional pra quem já resolveu ela.

Perguntas frequentes sobre Kafka

Kafka é um banco de dados?

Não. Kafka é um log de eventos distribuído, não um banco de dados. Ele guarda sequências de mensagens em ordem e permite lê-las de forma eficiente, mas não foi feito pra consultas por campos arbitrários, joins ou buscas pontuais. Se você precisa disso, use um banco relacional ou NoSQL. Kafka costuma alimentar bancos, não substituí-los.

Qual a diferença entre Kafka e RabbitMQ?

RabbitMQ é um message broker tradicional focado em roteamento e entrega de tarefas, onde a mensagem desaparece depois de consumida. Kafka é um log distribuído que guarda as mensagens por tempo configurável, permitindo que vários sistemas leiam o mesmo fluxo de forma independente e reprocessem dados antigos. Kafka ganha em throughput e reprocessamento, RabbitMQ ganha em flexibilidade de roteamento.

O que são producer e consumer no Kafka?

Producer é a aplicação que escreve eventos no Kafka, e consumer é a que lê esses eventos. O producer publica em um tópico sem saber quem vai ler, e o consumer lê no próprio ritmo, controlando com um offset até onde já processou. Vários consumers podem ler o mesmo tópico de forma independente, o que é uma das características centrais do Kafka.

Para que servem os tópicos e as partições?

O tópico é a categoria lógica onde os eventos ficam organizados, tipo “pedidos” ou “pagamentos”. A partição é a subdivisão do tópico que permite a escala: cada partição é um log ordenado, e distribuir um tópico em várias partições deixa vários consumers processarem em paralelo. A ordem das mensagens só é garantida dentro de uma mesma partição, por isso a chave da mensagem é usada pra manter eventos relacionados juntos.

Quando devo usar Kafka?

Use Kafka quando tem volume alto de eventos, precisa que vários sistemas consumam o mesmo fluxo de dados de forma independente, quer poder reprocessar dados históricos, ou está construindo pipelines de dados e arquiteturas orientadas a eventos. Se seu volume é baixo, você só precisa de request-reply simples, ou quer um banco de dados, Kafka provavelmente é a ferramenta errada.

Kafka é gratuito?

Sim. O Apache Kafka é open source e gratuito, mantido pela Apache Software Foundation. Você pode baixar, rodar e usar sem pagar nada. O custo aparece na operação: infraestrutura, monitoramento e tempo de time. Por isso muita gente opta por serviços gerenciados pagos como Confluent Cloud ou Amazon MSK, que cobram pela conveniência de não ter que administrar o cluster.

Conclusão

No fundo, Kafka é uma ideia simples levada a uma escala impressionante: um log de eventos ordenado, durável e replicado, do qual muitos sistemas leem de forma independente. Producer escreve, broker guarda, tópico organiza, partição escala, consumer lê. Depois que esses cinco conceitos fazem sentido, o resto é operação e afinação. A complexidade que assusta no começo mora quase toda na parte de rodar o cluster, não na parte de entender o que ele faz.

O conselho que eu daria pra quem está avaliando é resistir à tentação de usar Kafka só porque é o que todo mundo usa. Ele é excelente quando o problema é de streaming, alto volume e desacoplamento de sistemas, e é peso morto quando você só precisava de uma fila simples. Entenda o seu caso primeiro, e se ele pedir Kafka de verdade, comece por um serviço gerenciado e vá aprendendo a operar aos poucos. A ferramenta é sólida e vai estar lá quando você crescer.

Para quem constrói sistemas que precisam de dados oficiais, o Hub do Desenvolvedor mantém APIs de consulta de CNPJ e CPF na Receita Federal prontas para você integrar sem burocracia.