Kafka em Escala: Tiered Storage, KRaft e Exactly-Once

A abstração central do Kafka é o log de partição: uma sequência imutável, append-only, de registros ordenados por offset. Isso não é detalhe de implementação — é a decisão de design que explica tudo o mais. Filas tradicionais (SQS, RabbitMQ) deletam mensagens após o consumo; o Kafka retém. Isso permite múltiplos consumer groups lendo o mesmo dado de forma independente, reprocessamento determinístico e auditoria nativa. O preço é que o broker precisa gerenciar retenção ativa, e disco local vira gargalo em clusters com alto volume ou retenção longa.

Cada tópico é dividido em partições, cada partição replicada entre brokers conforme o fator de replicação configurado. O broker líder de cada partição aceita writes; os followers replicam de forma síncrona (se no ISR — In-Sync Replica set). Um producer escreve para o líder; o registro só é considerado committed quando todos os membros do ISR confirmam — esse é o contrato de durabilidade do Kafka. O parâmetro acks=all (ou acks=-1) junto com min.insync.replicas define o quórum mínimo de confirmação. Sem entender esse triângulo (líder, ISR, acks), qualquer discussão sobre exactly-once é prematura.

O modelo de segmentos é onde o Kafka ganha eficiência de I/O: cada partição no disco é uma sequência de segmentos (arquivos .log + índices de offset e timestamp). O broker só escreve no segmento ativo (tail); segmentos fechados são imutáveis. Isso permite sendfile() direto do filesystem cache para o socket do consumer — zero-copy — sem passar pelo heap da JVM. Em workloads de alto throughput, o Kafka frequentemente satura a rede antes do disco, justamente por esse design.

O ZooKeeper foi a escolha pragmática de 2011: um serviço de coordenação distribuída já maduro, que o Kafka usou para armazenar metadados de cluster (quais brokers estão vivos, quais são os líderes de partição, configurações de tópicos, ACLs). Funcionou por uma década, mas criou um acoplamento arquitetural caro: dois sistemas distribuídos para operar, dois modelos de segurança para configurar, e um gargalo de escala real — o ZooKeeper armazenava todos os metadados em memória, e clusters com centenas de milhares de partições começavam a sentir latência no controller election e na propagação de metadados.

O KRaft (Kafka Raft Metadata) resolve isso via KIP-500: os próprios brokers Kafka passam a executar um protocolo Raft interno para consenso de metadados. Um subconjunto de brokers (ou nodes dedicados de controller) forma o quórum de controllers; o controller ativo mantém um log de metadados replicado — o mesmo modelo de log/segmento do Kafka, aplicado a si mesmo. Isso elimina o ZooKeeper como dependência operacional e, mais importante, remove o limite prático de partições por cluster: benchmarks da Confluent mostraram recuperação de controller failure em segundos com KRaft vs. dezenas de segundos com ZooKeeper em clusters grandes.

A transição não foi trivial. O KIP-500 foi proposto em 2019; KRaft ficou em early access no Kafka 2.8 (2021), atingiu GA no 3.3 (2022) para novos clusters, e o suporte a migração de ZooKeeper para KRaft chegou no 3.5. O ZooKeeper foi oficialmente removido no Kafka 4.0 (2024). No Amazon MSK, clusters KRaft estão disponíveis a partir do Kafka 3.6 no MSK. O ponto operacional crítico: em modo KRaft, os controller nodes precisam de discos confiáveis e baixa latência de rede entre si — eles são o novo plano de controle do cluster. Em MSK, isso é abstraído; em clusters self-managed, é uma decisão de infraestrutura explícita.

O KIP-405 (Tiered Storage) resolve um problema econômico real: disco local em brokers Kafka é caro e não escala independentemente de compute. Em clusters com retenção de dias ou semanas, a maior parte dos dados está fria — raramente lida, mas precisa estar disponível para reprocessamento ou auditoria. Manter isso em EBS ou NVMe local é desperdício.

O mecanismo funciona assim: o RemoteLogManager (RLM), componente introduzido pelo KIP-405, monitora os segmentos fechados de cada partição. Quando um segmento atinge o critério de offload (configurável por tempo ou tamanho), o RLM faz upload do arquivo .log, dos índices de offset e timestamp, e dos metadados para o storage remoto — no caso do MSK, Amazon S3. Após confirmação do upload, o segmento local pode ser deletado, liberando disco. O broker mantém um mapa de metadados remotos que indica quais offsets estão em S3 vs. local.

Do ponto de vista do consumer, o protocolo é transparente: ele faz um FetchRequest normal para o broker líder. Se o offset solicitado está em storage remoto, o broker busca o dado no S3, faz o cache localmente (configurável), e retorna ao consumer. O consumer não sabe que o dado veio de S3. Isso é elegante, mas tem implicações de latência: um fetch de dado frio tem latência de S3 (tipicamente dezenas de ms) vs. disco local ou page cache (sub-ms). Para workloads de reprocessamento em lote, isso é aceitável; para consumidores que precisam de baixa latência em dados históricos, não é.

No Amazon MSK, o Tiered Storage é habilitado por configuração no cluster e usa S3 gerenciado pela AWS — você não configura o bucket diretamente, mas pode usar S3 Lifecycle Policies para controlar custo de armazenamento de longo prazo. A limitação atual: Tiered Storage no MSK não suporta todos os tipos de instância, e a compactação de log (log compaction) tem restrições com tiered storage habilitado — segmentos compactados não são elegíveis para offload em certas versões. Isso é crítico para tópicos de changelog (Kafka Streams, CDC).

Exactly-once no Kafka é implementado em duas camadas complementares, e confundir as duas é um erro comum em entrevistas e em produção.

Camada 1 — Producer Idempotente: habilitado com enable.idempotence=true (default true desde Kafka 3.0). O broker atribui ao producer um ProducerID (PID) e rastreia o número de sequência por partição. Se o producer retransmite uma mensagem (por timeout ou falha de rede), o broker detecta o número de sequência duplicado e descarta — sem duplicatas no log. Isso garante exactly-once por partição, por sessão de producer. Custo: praticamente zero — é bookkeeping no broker, sem coordenação distribuída adicional.

Camada 2 — Transações: habilitado com transactional.id no producer. O producer coordena com um Transaction Coordinator (um broker especial eleito por hash do transactional.id) para abrir, commitar ou abortar uma transação que pode abranger múltiplas partições e múltiplos tópicos. O mecanismo usa um two-phase commit interno: o coordinator grava o estado da transação em um tópico interno (__transaction_state) antes de instruir os brokers a marcar as mensagens como committed. Consumers com isolation.level=read_committed só veem mensagens de transações commitadas — mensagens de transações abertas ou abortadas são filtradas.

O custo real das transações é não-trivial: latência adicional de round-trip para o Transaction Coordinator, overhead de escrita no __transaction_state, e o risco de transações zumbis — producers que falharam sem abortar a transação, deixando-a aberta até o transaction.timeout.ms. Em sistemas de alto throughput, transações muito grandes (muitas mensagens em uma transação) ou muito frequentes (uma transação por mensagem) degradam throughput significativamente. A recomendação prática: batch suas transações por janela de tempo ou contagem de registros, não por mensagem individual.

Um ponto frequentemente ignorado: exactly-once end-to-end (producer → broker → consumer → sink) requer que o sink também seja idempotente ou transacional. O Kafka garante exactly-once no log; se o consumer processa e grava em um banco sem idempotência, você ainda tem at-least-once no sistema como um todo. O Kafka Streams implementa exactly-once end-to-end usando transações Kafka para coordenar leitura, processamento e escrita atomicamente — mas isso só funciona quando source e sink são ambos Kafka.

O modelo de consumer group é o que permite Kafka escalar o consumo horizontalmente: cada partição é atribuída a exatamente um consumer dentro do grupo, e múltiplos grupos podem consumir o mesmo tópico independentemente. O Group Coordinator (um broker eleito por hash do group.id) gerencia o ciclo de vida do grupo: join, sincronização de assignment, heartbeats e detecção de falhas.

O problema clássico é o rebalance: sempre que um consumer entra, sai, ou para de enviar heartbeats dentro de session.timeout.ms, o coordinator dispara um rebalance. No protocolo original (Eager Rebalance), todos os consumers do grupo param de consumir, revogam todas as partições, e aguardam o novo assignment. Em grupos grandes com muitas partições, isso pode causar pausas de segundos a dezenas de segundos — um stop-the-world distribuído.

O Kafka 2.4 introduziu o Cooperative Sticky Assignor (KIP-429/KIP-482), que implementa rebalance incremental: apenas as partições que precisam ser movidas são revogadas; as demais continuam sendo consumidas durante o rebalance. Isso reduz drasticamente o impacto, mas requer que todos os consumers do grupo usem um assignor cooperativo — um detalhe de configuração que frequentemente é esquecido em migrações.

Outro ponto operacional crítico: max.poll.interval.ms define o tempo máximo entre duas chamadas a poll(). Se o processamento de um batch demora mais que esse intervalo (processamento pesado, chamadas externas lentas), o consumer é considerado morto pelo coordinator e um rebalance é disparado — mesmo que o consumer esteja vivo e processando. Isso cria um loop de rebalances em workloads com processamento variável. A solução não é aumentar max.poll.interval.ms indefinidamente (isso atrasa a detecção de falhas reais), mas reduzir o tamanho do batch via max.poll.records para garantir que o processamento caiba dentro do intervalo configurado. No Amazon MSK, esses parâmetros são configuráveis por consumer — o MSK não os gerencia; eles ficam inteiramente na sua aplicação.