Kafka: streaming de eventos em larga escala

O que é Kafka e por que foi criado

A origem do Apache Kafka no LinkedIn

O Apache Kafka foi criado pelo LinkedIn em 2011 para resolver um problema específico: processar bilhões de eventos de atividade de usuários por dia sem sobrecarregar os bancos de dados relacionais. Diferente de sistemas de filas tradicionais como RabbitMQ, o Kafka foi projetado como um log distribuído e imutável de eventos, onde mensagens são retidas por um período configurável mesmo após serem consumidas. Essa decisão arquitetural muda completamente como sistemas distribuídos lidam com integração e reprocessamento de dados. Hoje, Kafka é usado por mais de 80% das empresas da Fortune 100 como espinha dorsal de pipelines de dados em tempo real.

Topics e partições — como o Kafka organiza dados

Paralelismo via particionamento

No Kafka, dados são organizados em topics, que funcionam como categorias lógicas de eventos. Cada topic é dividido em partições, que são a unidade de paralelismo do sistema. Cada partição é um log ordenado e imutável onde eventos são escritos sequencialmente com um offset crescente. A quantidade de partições define o nível máximo de paralelismo de consumo: com 12 partições, até 12 consumers de um mesmo grupo podem processar em paralelo. A escolha do número de partições é uma decisão de arquitetura importante, pois aumentar partições depois tem custos operacionais significativos.

Producers — publicando eventos no Kafka

Como dados chegam ao cluster

Producers são os responsáveis por publicar mensagens em topics do Kafka. Por padrão, o particionamento é feito com base em uma chave: mensagens com a mesma chave sempre vão para a mesma partição, garantindo ordenação por chave. Sem chave definida, o producer distribui mensagens entre partições usando round-robin ou sticky partitioning. Producers podem configurar o nível de durabilidade com o parametro acks: acks=0 ignora confirmações, acks=1 espera confirmação do leader, e acks=all exige confirmação de todas as replicas in-sync, garantindo zero perda de dados em falhas. A escolha de acks impacta diretamente o throughput e a latência do producer.

Consumers e consumer groups — processando em paralelo

Escalabilidade horizontal no consumo

Consumers se organizam em consumer groups para processar partições em paralelo. Cada partição é atribuída a exatamente um consumer dentro de um grupo, garantindo que cada mensagem seja processada uma única vez por grupo. Quando um consumer falha ou um novo é adicionado, o Kafka realiza um rebalanceamento automático, redistribuindo partições entre os consumers ativos. Múltiplos consumer groups independentes podem consumir o mesmo topic simultaneamente, cada um mantendo seu próprio offset, o que permite que sistemas diferentes processem os mesmos eventos sem interferência. Esse modelo é fundamental para fan-out de eventos em arquiteturas orientadas a eventos.

Offset — controlando o que já foi processado

O ponteiro de progresso do consumer

O offset é um número inteiro que identifica a posição de uma mensagem dentro de uma partição. Consumers armazenam seus offsets no topic interno __consumer_offsets do próprio Kafka, eliminando a dependência de sistemas externos para rastrear progresso. Consumers podem fazer commit de offsets automaticamente (auto.commit) ou manualmente, sendo o commit manual necessário para garantir processamento confiável: o offset só é commitado após a mensagem ser processada com sucesso. A capacidade de resetar offsets para uma posição anterior (earliest, latest ou timestamp específico) permite reprocessamento de eventos históricos sem republica-los, uma característica exclusiva de sistemas baseados em log imutável.

Retention e compaction — quanto tempo guardar eventos

Politicas de retenção no Kafka

O Kafka oferece duas estratégias de retenção de dados: baseada em tempo e em tamanho. Com retenção por tempo (retention.ms), mensagens são deletadas após um período configurável, tipicamente 7 dias em ambientes de produção. Com retenção por tamanho (retention.bytes), mensagens antigas são removidas quando a partição atinge o limite definido. Além dessas políticas, o Kafka oferece log compaction, onde apenas a mensagem mais recente de cada chave é mantida indefinidamente, descartando versões antigas. Log compaction é ideal para topics que representam estado atual, como configurações ou snapshots de entidades, onde o histórico completo não é necessário mas o último valor de cada chave deve ser preservado.

Kafka Connect — integrando com bancos e sistemas externos

Conectores prontos para uso

Kafka Connect é um framework para integração de dados entre Kafka e sistemas externos como bancos de dados, sistemas de arquivos, filas e APIs. Ele opera através de conectores divididos em dois tipos: Source Connectors, que leem dados de sistemas externos e publicam no Kafka, e Sink Connectors, que consomem do Kafka e escrevem em sistemas externos. O Debezium é um dos conectores mais populares, implementando Change Data Capture (CDC) para capturar alterações em bancos relacionais como PostgreSQL e MySQL e propagá-las como eventos no Kafka. Kafka Connect escala horizontalmente e gerencia offsets automaticamente, eliminando a necessidade de código customizado para pipelines de integração comuns.

Kafka Streams — processamento em tempo real

Transformações sobre streams de dados

Kafka Streams é uma biblioteca cliente Java/Scala para processamento de streams diretamente sobre dados do Kafka, sem necessidade de infraestrutura adicional como Spark ou Flink. Com Kafka Streams é possível filtrar, transformar, agregar, fazer join entre topics e construir tabelas KTable que representam o estado atual derivado de um stream de eventos. O processamento é stateful: a biblioteca gerencia state stores locais (baseados em RocksDB) para operações de agregação, com suporte nativo a windowing para calcular métricas em janelas de tempo deslizantes ou fixas. Por rodar como parte da aplicação, Kafka Streams tem overhead operacional mínimo comparado a frameworks de processamento distribuído separados.

Schema Registry — garantindo contratos de dados

Evolucao segura de esquemas em producao

O Schema Registry, desenvolvido pela Confluent, resolve um problema crítico em sistemas baseados em eventos: como garantir que producers e consumers concordam com o formato das mensagens ao longo do tempo. Ele armazena schemas Avro, JSON Schema ou Protobuf centralizados, e producers serializam mensagens incluindo o ID do schema usado. Consumers recuperam o schema pelo ID para deserializar corretamente, sem precisar de coordenação manual. O Schema Registry aplica regras de compatibilidade, como backward compatibility (novos schemas conseguem ler mensagens antigas) e forward compatibility (schemas antigos conseguem ler mensagens novas), prevenindo que mudanças de schema quebrem consumers em producao sem necessidade de deployar todos os servicos simultaneamente.

Kafka em producao — observabilidade e operações

Monitoramento de clusters Kafka

Operar Kafka em producao exige monitoramento de métricas críticas: consumer lag (diferenca entre o offset mais recente publicado e o offset commitado pelo consumer) indica acúmulo de mensagens nao processadas. Métricas de under-replicated partitions alertam sobre replicas que estao atrasadas em relacao ao leader, indicando risco de perda de dados em caso de falha. O Kafka usa o ZooKeeper (ou o KRaft mode nas versoes mais recentes) para coordenacao de cluster, eleicao de leaders e armazenamento de metadados. Ferramentas como Kafka UI, Conduktor e Confluent Control Center oferecem visibilidade operacional sobre topicos, consumer groups e throughput do cluster em tempo real.

Conclusao — Kafka como espinha dorsal de sistemas distribuidos

Quando adotar Kafka em sua arquitetura

Kafka e a escolha certa quando o volume de eventos supera o que bancos de dados e filas tradicionais conseguem absorver, quando voce precisa de reprocessamento histórico, ou quando múltiplos sistemas precisam consumir os mesmos eventos de forma independente. A curva de aprendizado e o custo operacional sao maiores que alternativas como RabbitMQ ou SQS, mas a escalabilidade e a durabilidade justificam o investimento em sistemas de missao critica. Continue em: Fundamentos obrigatórios antes de produção.