Glossário

No contexto do Kafka, ACK (acknowledgment) é a configuração do producer (acks) que define quanta confirmação ele exige antes de considerar uma escrita bem-sucedida: acks=0 não espera confirmação nenhuma (mais rápido, mais arriscado), acks=1 espera confirmação apenas do leader, e acks=all espera confirmação de todas as réplicas no ISR (mais lento, mais durável). Esse trade-off é central na discussão de garantias de entrega.

Um broker é uma instância do servidor Kafka em execução. Ele armazena fisicamente os dados de uma ou mais partitions e responde a requisições de producers (escrita) e consumers (leitura) para essas partitions. Um cluster Kafka é composto por múltiplos brokers, cada um responsável por um subconjunto das partitions de todos os tópicos — e, para cada partition, um broker atua como leader e os demais (se houver réplicas) como followers.

O cluster é a unidade de implantação do Kafka: um grupo de brokers coordenados entre si (via KRaft nas versões atuais) que, em conjunto, oferecem tolerância a falhas e distribuição de carga. Tópicos e suas partitions são distribuídos entre os brokers do cluster; perder um broker não derruba o cluster inteiro, desde que as partitions afetadas tenham réplicas em outros brokers.

Commit é a operação que registra, para um Consumer Group, até qual offset de uma partition já foi processado com sucesso. Pode ser automático (enable.auto.commit=true, o client comita periodicamente em background) ou manual (a aplicação decide exatamente quando comitar, tipicamente depois de confirmar que o processamento da mensagem terminou). A escolha entre auto commit e commit manual define o comportamento do consumer diante de uma falha: o que já foi processado mas ainda não comitado é reprocessado do zero após um restart ou rebalance.

Um consumer lê registros de uma ou mais partitions de um tópico, avançando sequencialmente a partir do último offset processado. Consumers quase sempre operam dentro de um Consumer Group, que determina como as partitions do tópico são divididas entre as instâncias em execução.

Dentro de um Consumer Group, cada partition de um tópico é atribuída a exatamente um consumer do grupo em um dado momento — o que distribui trabalho, similar a uma fila. Consumer Groups diferentes, no entanto, são totalmente independentes entre si: cada grupo mantém seu próprio conjunto de offsets e pode ler o mesmo tópico sem interferir nos demais. É essa combinação que permite ao Kafka tanto distribuir trabalho quanto compartilhar o mesmo dado com múltiplos sistemas.

Consumer lag é a métrica mais importante para saber se um Consumer Group está acompanhando o ritmo de produção de um tópico. Calculado por partition como log end offset - offset commitado, ele representa quantas mensagens já foram escritas mas ainda não foram processadas. Lag zero significa que o consumer está em dia; lag crescente ao longo do tempo indica que o consumer processa mais devagar do que o producer escreve — um sinal de que é preciso investigar throughput de processamento, aumentar paralelismo (mais partitions e consumers, Capítulo 6) ou otimizar o código do consumer.

DLQ (Dead Letter Queue, ou Dead Letter Topic no vocabulário do Kafka) é um tópico dedicado para onde mensagens que falharam repetidamente no processamento são publicadas, depois de esgotadas as tentativas de retry. O Kafka não tem um mecanismo nativo de DLQ como o SQS — ela é implementada pela aplicação (ou pelo framework, como o Spring Kafka via DeadLetterPublishingRecoverer), publicando a mensagem problemática em um tópico separado. O principal benefício é isolar o efeito "poison pill": uma mensagem que trava o processamento não bloqueia as demais mensagens da mesma partition indefinidamente.

Um event (evento) é a unidade fundamental de dado no Kafka: um registro imutável, publicado em um tópico, representando um fato de negócio que já ocorreu — "pagamento aprovado", "PIX recebido", "conta bloqueada". Diferente de um comando (que instrui uma ação futura), um evento apenas relata algo que já aconteceu; quem o consome decide, de forma independente, o que fazer com essa informação. É essa natureza — fato passado, não instrução — que permite que múltiplos consumidores reajam ao mesmo evento de formas completamente diferentes, sem que o producer precise conhecer nenhum deles.

Um follower mantém uma cópia dos dados da partition que replica, buscando continuamente os novos registros do leader. Ele não serve leituras nem escritas de clientes diretamente (na configuração padrão) — sua função é permitir que, se o leader falhar, um follower atualizado assuma como novo leader sem perda de dados confirmados.

Idempotência, no contexto de consumers Kafka, é a capacidade de processar o mesmo evento múltiplas vezes sem gerar efeitos colaterais duplicados — creditar um saldo duas vezes, enviar dois e-mails, gerar duas cobranças. É um requisito, não um extra, porque garantias at-least-once (a configuração mais comum em produção) implicam que o mesmo evento pode ser entregue mais de uma vez, por causa de retries, rebalances ou falhas entre o processamento e o commit do offset. A implementação mais comum usa um identificador único do evento (eventId) e uma constraint de unicidade em banco de dados, verificada e aplicada na mesma transação que executa o efeito de negócio.

ISR (In-Sync Replicas) é a lista de réplicas de uma partition — incluindo o próprio leader — que estão em dia com os dados confirmados. Apenas followers no ISR são elegíveis para eleição como novo leader em caso de falha, evitando que uma réplica atrasada assuma e cause perda de dados já confirmados a producers.

A key é o mecanismo que garante ordenação relativa entre mensagens: todas as mensagens com a mesma key caem na mesma partition (via hash da key), e portanto são lidas na ordem em que foram escritas. Mensagens sem key são distribuídas entre partitions de forma aproximadamente uniforme (round-robin/sticky), sem garantia de ordenação entre elas.

Cada partition tem exatamente um broker atuando como leader a qualquer momento. Producers e consumers interagem com a partition através do leader; os demais brokers que possuem réplica dessa partition atuam como followers, replicando os dados do leader. Se o leader falha, um follower atualizado é eleito novo leader.

O offset é um número inteiro crescente, único por partition, que marca a posição de um registro no log. Ele não é global ao tópico — é local a cada partition; a mesma numeração de offset existe de forma independente em cada partition. Consumers usam o offset para saber até onde já leram, e o commit do offset (automático ou manual) é o que marca esse progresso.

Uma partition é a unidade real de armazenamento e paralelismo no Kafka. Cada partition é um log append-only: novos registros são sempre adicionados ao final, identificados por um offset crescente. Partitions existem por dois motivos — paralelismo (múltiplos consumers podem processar partitions diferentes ao mesmo tempo) e escalabilidade (um tópico cresce distribuindo suas partitions entre mais brokers). A key da mensagem determina em qual partition ela é armazenada.

O producer é o papel assumido por qualquer aplicação — normalmente um microsserviço — que envia mensagens a um tópico. Ele decide o tópico de destino, a key da mensagem (que determina a partition) e o formato de serialização do valor. Um producer não conhece seus consumers; essa ausência de acoplamento é o que viabiliza a arquitetura orientada a eventos.

Rebalance é o processo pelo qual o coordenador do Consumer Group redistribui as partitions de um tópico entre os consumers ativos, sempre que a composição do grupo muda — um consumer cai, um novo entra, ou um consumer é considerado morto por não enviar heartbeat a tempo. Durante o rebalance, o consumo do grupo pausa brevemente enquanto as partitions são reatribuídas; estratégias de rebalance mais recentes (cooperative sticky) reduzem esse impacto ao evitar revogar partitions de consumers que continuam ativos.

Replay é a capacidade de reler eventos já retidos no log, movendo o offset de um Consumer Group (ou de uma nova instância dele) para uma posição anterior — ou para o início da retenção disponível. É usado para corrigir bugs de processamento, popular um novo sistema com histórico existente ou reconstruir um estado derivado (como um índice de busca). Depende diretamente da política de retenção do tópico: só é possível reler o que ainda não expirou.

Replication factor é configurado por tópico e determina quantas réplicas de cada partition existem no cluster — uma delas atuando como leader e as demais como followers. Um replication factor de 3 significa que o cluster pode perder até 2 brokers responsáveis por réplicas dessa partition sem perder dados confirmados, desde que as réplicas restantes estejam no ISR no momento da falha. Replication factor não deve ser confundido com número de partitions: um define quantas cópias existem de cada partition (disponibilidade), o outro define em quantas fatias o tópico é dividido (paralelismo e escala).

Retention (retenção) determina quando um registro pode ser descartado do log — por tempo (ex.: 7 dias) ou por tamanho acumulado da partition, o que ocorrer primeiro. Diferente de uma fila, a retenção no Kafka não depende de o registro já ter sido consumido: ele permanece disponível para qualquer consumer (existente ou futuro) até expirar pela política configurada. É a retenção que viabiliza o replay.

Retry é a tentativa de reprocessar uma mensagem depois de uma falha, partindo da premissa de que o erro pode ser transitório (banco de dados momentaneamente indisponível, timeout de rede) e que uma nova tentativa, talvez segundos ou minutos depois, tem chance de suceder. A prática recomendada é usar backoff exponencial (o intervalo entre tentativas cresce a cada falha) e um limite máximo de tentativas, após o qual a mensagem é encaminhada para uma DLQ em vez de ser tentada indefinidamente.

Throughput mede quantas mensagens um producer consegue publicar, ou um consumer consegue processar, por segundo. É a métrica de capacidade que, combinada com consumer lag, diagnostica se um pipeline está saudável: throughput de consumo menor que throughput de produção, sustentado ao longo do tempo, é exatamente o que faz o consumer lag crescer indefinidamente. Aumentar throughput de consumo geralmente significa aumentar paralelismo (mais partitions e consumers, Capítulo 6) ou reduzir o custo de processamento por mensagem — raramente ajustar throughput sem entender qual dos dois lados está gargalando.

Um topic é a abstração que producers e consumers enxergam — por exemplo, pagamentos.aprovados. Ele não tem um schema imposto pelo Kafka em si; o que ele garante é a divisão em partitions, cada uma um log ordenado e imutável. A ordem de entrega é garantida dentro de cada partition do tópico, não entre tópicos diferentes, nem necessariamente entre partitions do mesmo tópico.