Diagrama de arquitetura do Kafka: brokers, partições, réplicas e consumer groups

É fácil desenhar o Kafka como uma única caixa com o rótulo "Kafka" e setas entrando e saindo, e essa caixa esconde todas as propriedades em que as pessoas confiam: o que é ordenado e o que não é, quantas cópias dos dados existem, o que acontece quando um broker cai e como vários serviços conseguem ler o mesmo stream sem atrapalhar uns aos outros.

Este artigo desenha um cluster Kafka com as partes que importam: brokers, tópicos e partições, réplicas líder e seguidoras, producers com chaves, consumer groups e offsets, e os controladores KRaft que gerenciam o cluster.

Tópicos, partições e brokers

Um tópico é um stream nomeado de registros, como orders. Cada tópico é dividido em partições, e cada partição é um log só de acréscimo em que cada registro recebe um offset crescente.

As partições são a unidade de tudo:

• Ordenação: os registros são ordenados dentro de uma partição, nunca entre partições.
• Paralelismo: um tópico pode ser consumido por no máximo tantos consumers de um grupo quanto o número de partições que ele tem.
• Distribuição: as partições ficam espalhadas pelos brokers, os servidores do cluster.

Escolha o número de partições pela vazão que você precisa por tópico e pelo número de consumers que quer rodar em paralelo, com folga. Dá para adicionar partições depois, mas isso muda a partição para a qual cada chave é mapeada.

Replicação

Cada partição tem um fator de replicação, normalmente 3. Uma réplica é a líder e atende leituras e escritas; as outras são seguidoras que copiam o log da líder. As seguidoras em dia formam o conjunto de réplicas sincronizadas (ISR). Se o broker de uma líder cair, uma seguidora em dia vira a nova líder.

As configurações que decidem a durabilidade:

Com fator 3, min.insync.replicas=2 e acks=all, uma escrita confirmada existe em pelo menos dois brokers, e o cluster continua aceitando escritas com um broker fora do ar. A documentação do Kafka cobre essas configurações e como elas interagem.

Producers e chaves

Os producers escolhem uma partição para cada registro. Com chave, o particionador padrão calcula o hash da chave, então todos os registros com a mesma chave caem na mesma partição e continuam em ordem. Sem chave, os registros são espalhados para equilibrar a carga e perdem qualquer ordem entre si.

Escolha as chaves pela entidade cujos eventos precisam ficar em ordem: um ID de pedido, um ID de conta. Escreva a chave junto do producer no diagrama; é a configuração de maior consequência que um producer tem. Evite chaves com poucos valores gigantes, porque uma chave quente sobrecarrega uma partição, não importa quantas você tenha.

Retries podem duplicar registros. As versões recentes do Kafka ativam producers idempotentes por padrão, o que remove duplicatas causadas por retries do producer dentro de uma partição; duplicatas vindas dos retries da sua própria aplicação ainda são possíveis, então os consumers também devem ser idempotentes.

Consumer groups e offsets

Um consumer group é um conjunto de consumers que dividem o trabalho para um mesmo propósito. O Kafka atribui cada partição a exatamente um consumer do grupo, então três partições mantêm ocupados no máximo três consumers; um quarto ficaria ocioso. Quando consumers entram ou saem, o grupo faz um rebalanceamento e as partições mudam de dono.

Cada grupo acompanha a própria posição, o offset confirmado por partição, que o Kafka guarda num tópico interno. É assim que vários serviços leem o mesmo stream de forma independente: fulfillment e analytics têm cada um seu grupo e seus offsets, e um não afeta o outro.

Faça o commit dos offsets depois do processamento, não antes, e você terá processamento at-least-once: depois de uma queda, o consumer reprocessa os registros desde o último commit. Torne o processamento idempotente para que as repetições sejam inofensivas.

Retenção e compactação

O Kafka mantém os registros depois que eles são lidos. A retenção por tempo ou tamanho apaga segmentos antigos, digamos depois de 7 dias. Já a compactação de log mantém para sempre o registro mais recente de cada chave, o que transforma um tópico num changelog do estado atual. Escolha por tópico: eventos costumam usar retenção, e um estado como "endereço mais recente por cliente" usa compactação.

Um exemplo de dimensionamento

Digamos que o checkout produza 3.000 eventos de pedido por segundo no pico, com cerca de 1 KB cada, ou seja, 3 MB/s. Um consumer do serviço de fulfillment processa 400 eventos por segundo. Você precisa de pelo menos 8 consumers em paralelo no pico, então de pelo menos 8 partições; escolha 12 para deixar espaço para crescimento e para as partições de um consumer que falhar. Com fator de replicação 3, o cluster grava 9 MB/s em disco entre os brokers, e 7 dias de retenção nesse ritmo armazenariam até cerca de 5,4 TB de dados replicados. O tráfego médio é menor que o pico, então trate esse número como o teto para planejar os discos. Números assim pertencem ao lado do diagrama, porque são eles que decidem o número de brokers e os discos, não a caixa com o rótulo Kafka.

KRaft: sem ZooKeeper

Clusters antigos guardavam seus metadados no ZooKeeper. Hoje o Kafka gerencia os metadados sozinho, com um quórum de controladores baseado em Raft, chamado KRaft. O Kafka 4.0, lançado em março de 2025, é a primeira versão principal que roda inteiramente sem ZooKeeper. No diagrama, desenhe o quórum de controladores separado dos brokers, mesmo quando clusters pequenos rodam os dois papéis nas mesmas máquinas.

O diagrama de arquitetura

Como ler:

• Esquerda: dois producers enviam eventos com o ID do pedido como chave. O pedido 8812 vai por hash para a partição 0, e o pedido 9001 para a partição 2.
• Centro: três brokers, cada um líder de uma partição e seguidor das outras duas. As arestas tracejadas mostram a replicação; os controladores KRaft abaixo gerenciam os metadados e a eleição de líder.
• Direita: o grupo fulfillment tem três consumers, um por partição. O consumer analytics pertence a outro grupo, então lê todos os eventos com seus próprios offsets.
• O bloco Markdown lista as configurações do tópico das quais o desenho depende.

O que colocar num diagrama do Kafka

• Partições por tópico e a chave, porque definem a ordenação e o paralelismo.
• Fator de replicação e min.insync.replicas, porque definem a durabilidade.
• Cada consumer group pelo nome, com seus consumers.
• Retenção ou compactação de cada tópico.
• Quem produz e quem consome, entre serviços, para deixar clara a responsabilidade.

Para os padrões construídos sobre o Kafka, veja o diagrama de arquitetura orientada a eventos, o padrão transactional outbox para publicar com segurança a partir de um banco de dados, e o diagrama de arquitetura de pipeline de dados para o Kafka alimentando a análise de dados.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione nós Contêiner do pack Modelo C4 para os producers, com a chave de cada um na descrição.
3. Adicione três nós Kafka do pack Dados para os brokers, rotulados com as partições que lideram e seguem, e um Contêiner para os controladores KRaft.
4. Adicione uma Moldura do pack Básico para o consumer group com um Contêiner por consumer, mais um consumer separado para o segundo grupo.
5. Desenhe a replicação como arestas tracejadas e adicione um bloco Markdown do pack Básico com as configurações do tópico.

O exemplo usa 12 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

O Kafka garante a ordem das mensagens? Dentro de uma partição, sim. Entre partições, não. Use uma chave para que registros que precisam ficar em ordem compartilhem uma partição.

Quantas partições um tópico deve ter? O suficiente para a vazão que você precisa e para o número de consumers que quer em paralelo, com espaço para crescer. Mudar o número depois muda como as chaves são mapeadas para as partições.

O que acontece quando um broker cai? Para cada partição da qual ele era líder, uma seguidora em dia em outro broker vira líder. Com fator de replicação 3 e min.insync.replicas=2, as escritas continuam.

O que é um consumer group? Um conjunto de consumers que dividem entre si as partições de um tópico. Grupos diferentes leem o mesmo tópico de forma independente, cada um com seus próprios offsets.

O Kafka ainda precisa do ZooKeeper? Não. O Kafka 4.0 e as versões seguintes rodam só no modo KRaft, em que um quórum de controladores gerencia os metadados do cluster.

Comece grátis — um assento, sem cartão de crédito.