Arquitetura Kafka: Brokers, Topics, Partitions e Offsets

Mergulhe na arquitetura distribuída do Kafka e entenda como seus componentes trabalham juntos para processar trilhões de eventos.

A Arquitetura Distribuída

No artigo anterior, vimos que o Kafka é uma plataforma de streaming que processa mais de 1,1 trilhão de mensagens por dia globalmente. Mas como ele consegue essa escala impressionante?

A resposta está na sua arquitetura distribuída. Diferente de filas tradicionais que centralizam mensagens em um único servidor, o Kafka distribui dados entre múltiplos brokers, usa partições para paralelismo e rastreia posição através de offsets. Cada decisão de design foi pensada para maximizar throughput sem sacrificar durabilidade.

Brokers: Os Servidores do Cluster

Um Broker é um servidor Kafka que armazena dados e atende requisições de clientes. Em produção, um cluster Kafka típico possui múltiplos brokers para garantir alta disponibilidade e distribuir a carga.

Como os Brokers Funcionam

Cada broker no cluster:

Armazena partições de um ou mais topics
Recebe mensagens dos producers e as persiste em disco
Atende requisições de consumers para leitura de dados
Replica dados para outros brokers (tolerância a falhas)

Identificação e Coordenação

Cada broker possui um ID único no cluster. Um dos brokers assume o papel de Controller, responsável por gerenciar a eleição de líderes para partições, detectar falhas de brokers e coordenar operações administrativas.

Alta Disponibilidade

Para garantir que o cluster continue operando mesmo com falhas, configure:

Mínimo de 3 brokers em produção
Replication factor ≥ 3 para topics críticos
min.insync.replicas = 2 para garantir durabilidade

Topics: Organizando Seus Eventos

Um Topic é uma categoria ou feed de mensagens. Pense nele como uma tabela em um banco de dados, mas otimizada para streaming.

Exemplo Real: Topics de um E-commerce

Um e-commerce típico organiza eventos em topics separados:

pedidos - Novos pedidos realizados pelos clientes
pagamentos - Transações de pagamento processadas
estoque - Atualizações de inventário
notificacoes - Emails e alertas para clientes

Partitions: A Chave para Escalabilidade

Partitions são a unidade fundamental de paralelismo no Kafka. Cada topic é dividido em uma ou mais partitions, e cada partition é um log ordenado e imutável de mensagens.

Por que Partitions são Importantes?

Paralelismo: Múltiplos consumers podem ler de diferentes partitions simultaneamente
Ordenação: Mensagens são ordenadas dentro de cada partition
Distribuição: Partitions são distribuídas entre brokers para balanceamento de carga

Garantindo Ordem de Pedidos por Cliente

Um cliente faz 3 pedidos em sequência. Precisamos garantir que sejam processados na ordem correta. A solução é usar ocliente_id como chave: todos os pedidos do mesmo cliente vão para a mesma partition, garantindo ordem de processamento.

Dimensionando Partitions

A Confluent recomenda 10-20 MB/s por partition. Para um e-commerce com pico de 50 MB/s em pedidos:

Partitions = 50 MB/s / 10 MB/s = 5 partitions (arredonde para 6)

Importante: Partitions não podem ser reduzidas depois de criadas. Comece conservador e aumente conforme necessário.

Offsets: Rastreando a Posição nas Mensagens

O Offset é um identificador sequencial único atribuído a cada mensagem dentro de uma partition. É o mecanismo que permite rastrear o progresso e habilita funcionalidades como replay.

Monitorando Lag de Processamento

Um sistema de detecção de fraude precisa processar pagamentos em tempo real. Se o consumer ficar atrasado (lag alto), fraudes podem passar despercebidas. O lag é calculado como:

LAG = LOG-END-OFFSET - CURRENT-OFFSET

Reprocessando Dados após Correção de Bug

Um bug no sistema calculou frete errado para 1.000 pedidos. Com offsets, você pode reprocessar a partir de um offset específico, recalcular o frete correto e atualizar os pedidos sem perder dados ou duplicar processamento.

Commit de Offsets: At-Least-Once vs At-Most-Once

O momento do commit define a semântica de processamento:

At-Least-Once: Commit APÓS processamento - garante que nenhuma mensagem seja perdida, mas pode haver duplicação
At-Most-Once: Commit ANTES do processamento - garante que não há duplicação, mas mensagens podem ser perdidas em falhas

Boas Práticas

Faça

Use cliente_id ou pedido_id como chave para garantir ordenação por entidade
Monitore o LAG com alertas quando lag > threshold definido
Configure replication factor ≥ 3 para dados críticos como pagamentos
Use commit manual para garantir processamento at-least-once

Evite

Partitions demais - 6-12 partitions é suficiente para maioria dos casos
Auto-commit com dados financeiros - risco de perda ou duplicação
Ignorar monitoramento de lag - pode causar atrasos críticos no processamento

Conclusão

A arquitetura distribuída do Kafka é o que permite processar trilhões de eventos com alta disponibilidade e baixa latência:

Brokers distribuem a carga e garantem disponibilidade - use pelo menos 3 em produção
Topics organizam eventos por domínio (pedidos, pagamentos, estoque)
Partitions habilitam paralelismo - use chaves para garantir ordenação por entidade
Offsets rastreiam posição - permitem replay e recuperação de falhas