O Apache Kafka 4.2.0 foi lançado oficialmente em 17 de fevereiro de 2026.

Como acontece em quase toda release relevante, a lista de mudanças é longa. Mas, para quem trabalha com sistemas reais, o ponto não é decorar KIPs.

O que importa é entender onde a nova versão mexe de verdade: consumo, filas, Streams, observabilidade, segurança, Connect e upgrade.

Este post resume justamente isso.

O que mais chama atenção na 4.2.0

Se fosse para resumir a release em uma frase, ela seria esta:

o Kafka 4.2.0 não traz só novas features. Ele deixa vários comportamentos mais maduros para produção.

Os destaques mais relevantes são estes:

  • share groups agora são considerados prontos para produção
  • o Streams Rebalance Protocol entrou em GA no seu conjunto principal de funcionalidades
  • ferramentas e métricas ficaram mais consistentes
  • o Kafka Connect ganhou melhorias práticas de integração e controle
  • o upgrade exige atenção em alguns pontos, principalmente para quem usa Streams

No fim, é uma release menos "cosmética" e mais operacional.

Share Groups: Kafka mais forte para cenários de fila

A mudança mais simbólica da 4.2.0 é a maturidade dos share groups, base da proposta de Queues for Kafka.

No modelo tradicional de consumer group, cada partition fica atribuída a apenas um consumer do grupo por vez.

Já nos share groups, a ideia é atender melhor cenários em que o processamento acontece registro por registro, com comportamento mais próximo de fila cooperativa do que de leitura ordenada por stream.

Na prática, isso significa que o Kafka passa a atender esse tipo de necessidade com menos improviso arquitetural.

A release oficial destaca alguns avanços importantes nesse modelo:

  • novo tipo de acknowledgement RENEW, útil para tempos de processamento mais longos
  • métricas de lag mais completas para share groups
  • controles mais claros sobre quantidade de registros buscados
  • batching adaptativo nos coordenadores ligados a esse tipo de grupo
  • contagem de tentativas de entrega por registro

Esse conjunto é importante porque torna o recurso menos experimental e mais operável.

Um exemplo mais próximo de backend é o de uma aplicação que publica eventos de pedido, pagamento e entrega em Kafka, mas ainda mantém outra fila só para tarefas assíncronas como enviar e-mail, gerar boleto, montar relatório ou reprocessar webhook. Com share groups, esse time passa a enxergar a possibilidade real de consolidar parte desse fluxo em uma única plataforma, desde que a semântica do caso de uso faça sentido nesse modelo.

Também vale notar o recado implícito da própria documentação: share groups não existem para substituir automaticamente consumer groups.

Eles fazem mais sentido quando os registros são processados individualmente, não quando a necessidade principal é manter um fluxo ordenado como stream.

Kafka Streams: rebalance mais maduro e mais visível

Outra mudança grande está no Kafka Streams.

A 4.2.0 coloca o Streams Rebalance Protocol como pronto para produção no seu conjunto principal de recursos.

Isso importa porque o rebalance em Streams é mais caro do que em um consumo simples.

Não se trata apenas de redistribuir partitions. Há redistribuição de tarefas, impacto em state stores, custo de coordenação e reflexo direto em estabilidade de throughput e tempo de recuperação.

Segundo a documentação oficial, o protocolo broker-driven foi desenhado justamente para entregar:

  • rebalances mais rápidos
  • comportamento mais estável
  • melhor observabilidade

Esse ponto conversa diretamente com o problema discutido no post sobre rebalance: em sistemas distribuídos, reorganizar consumo tem custo. A novidade aqui é que o Streams ganha um protocolo mais maduro para lidar com isso.

Além disso, a 4.2.0 trouxe outras melhorias úteis para Streams:

  • suporte a dead letter queue em exception handlers
  • anchored wall-clock punctuation, para agendamentos mais determinísticos
  • controle explícito sobre envio de leave group ao fechar a aplicação
  • novas métricas para callbacks de rebalance
  • opção de permissão de escrita por grupo do sistema operacional no diretório local de estado

O suporte a dead letter queue merece destaque.

Em aplicações de stream processing, erro de dado quase nunca é um caso teórico. Sempre existe o evento inválido, malformado ou inesperado. Conseguir tratar isso de forma explícita melhora bastante a robustez operacional.

Já o anchored punctuation resolve uma dor mais sutil, mas muito comum: tarefas agendadas com referência temporal previsível, em vez de comportamento relativo ao instante de inicialização da aplicação.

Um exemplo mais próximo de backend é um serviço que consome eventos de pedido, cruza com dados de pagamento e estoque e mantém uma visão materializada para consulta da API. Se ele depende de state store local e precisa recalcular janelas ou agregações em horários previsíveis, essas melhorias deixam o comportamento bem mais controlável após reinício ou rebalance.

Observabilidade e operação ficaram mais consistentes

Boa parte do valor da 4.2.0 aparece quando olhamos para operação.

A release trouxe melhorias que não parecem enormes isoladamente, mas reduzem bastante atrito no dia a dia.

Uma delas é a padronização de argumentos nas ferramentas de linha de comando, com opções como --bootstrap-server e --command-config se tornando mais consistentes entre utilitários.

Pode parecer detalhe pequeno, mas quem automatiza administração e troubleshooting sabe o custo de ferramentas que seguem padrões diferentes entre si.

Outro avanço importante é a correção de nomenclatura de métricas para o padrão kafka.COMPONENT.

Esse tipo de ajuste melhora a vida de quem mantém dashboards, alertas e séries históricas e não quer descobrir em produção que uma métrica mudou de nome de maneira inconsistente.

A 4.2.0 também adiciona:

  • métricas de idle ratio para controller e MetadataLoader
  • métricas genéricas de nível de feature
  • possibilidade de consultar features suportadas por nó específico
  • exposição de rack id via API administrativa para membros de consumer groups e share groups
  • batching adaptativo em group coordinators

Esse bloco de mudanças não costuma chamar tanta atenção em anúncio de release, mas melhora bastante a capacidade de diagnóstico e leitura do cluster.

Um caso bem comum em backend é o de um time que mantém APIs e consumidores Kafka e precisa diagnosticar lag, rebalance ou erro de conexão sem depender toda vez de alguém da infraestrutura. Quando CLI e métricas seguem padrões mais consistentes, troubleshooting, dashboards e automações internas ficam bem menos frágeis.

Connect e segurança também evoluíram

No Kafka Connect, a 4.2.0 traz melhorias pontuais, mas úteis.

A primeira é o suporte a schema externo no JsonConverter.

Em alguns cenários, isso ajuda a reduzir payload e simplificar integrações baseadas em JSON, principalmente quando não faz sentido transportar schema completo em todas as mensagens.

A segunda é uma nova política de allowlist para sobrescrita de configurações de cliente por conectores.

Esse é um ponto importante de segurança e governança. Em ambientes com vários times publicando conectores, dar liberdade irrestrita para override de configs costuma virar fonte de risco operacional.

Além disso, a release reforça segurança e consistência com outros ajustes, como:

  • depreciação de org.apache.kafka.disallowed.login.modules em favor de org.apache.kafka.allowed.login.modules
  • exigência de que KafkaPrincipalBuilder implemente KafkaPrincipalSerde
  • melhoria de thread-safety em RecordHeader

Essa última merece menção especial porque elimina risco de leitura concorrente insegura em headers de ConsumerRecord.

Um exemplo prático é o de um backend que precisa integrar banco, busca e analytics via Connect, mas não quer que cada novo conector criado por outro time sobrescreva livremente parâmetros sensíveis do cliente. A allowlist ajuda a limitar esse poder de customização sem bloquear por completo a flexibilidade da plataforma.

Pequenas mudanças que importam mais do que parecem

Além dos destaques maiores, a 4.2.0 também entrega melhorias de base que tendem a aparecer como estabilidade, não como marketing.

Entre elas:

  • suporte a Java 25
  • configuração dinâmica para remote.log.manager.follower.thread.pool.size
  • depreciação de remote.log.manager.thread.pool.size
  • correções e padronizações em validação de configurações do tipo lista
  • depreciação de opções antigas e nomes incorretos em algumas configs e ferramentas
  • depreciação do parâmetro --max-partition-memory-bytes no kafka-console-producer, substituído por --batch-size

Esse tipo de ajuste reduz atrito em manutenção, upgrade e operação contínua.

Um exemplo mais próximo de backend é o de pipelines de deploy, scripts de suporte e jobs operacionais que ficaram anos usando parâmetros antigos de CLI ou configs pouco claras. Quando a release organiza isso melhor, o ganho não aparece como nova feature de produto, mas como menos incidente escondido no dia a dia.

O que merece atenção antes de atualizar

A 4.2.0 é uma release madura, mas não deve ser tratada como atualização trivial.

O guia oficial destaca alguns cuidados importantes.

O primeiro é que share groups estão prontos para produção, mas continuam sendo um modelo específico de consumo. Não é algo para sair trocando automaticamente no lugar de todo consumer group.

O segundo é que o Streams Rebalance Protocol entrou em GA, mas a documentação também registra um ponto importante: existe uma recomendação explícita para não fazer migração offline de classic para streams groups na 4.2.0 por causa de um bug crítico no lado do broker. Grupos Streams novos não são afetados.

O terceiro é o upgrade de Kafka Streams.

Segundo o guia oficial de upgrade do Streams, se a aplicação estiver vindo de versões 3.4 ou anteriores, o caminho seguro até 4.2.0 pode exigir dois rolling bounces com a configuração upgrade.from na primeira etapa e sua remoção na segunda.

Esse detalhe existe por causa de mudanças de serialização internas. Ignorar isso é exatamente o tipo de erro que faz upgrade parecer simples até começar a quebrar em produção.

Um cenário típico de backend é o de um time que atualiza a imagem do serviço de processamento e assume que basta trocar a versão da aplicação e fazer rolling update. Na 4.2.0, isso pode ser perigoso se a aplicação Streams vier de uma versão mais antiga, porque a ordem do upgrade passa a importar de verdade.

O que a 4.2.0 muda para os times na prática

Se eu resumisse o impacto da 4.2.0 para times de engenharia, seria assim:

  • o Kafka fica mais pronto para casos de fila cooperativa
  • o Streams ganha um rebalance mais maduro e mais observável
  • operação e monitoramento ficam menos inconsistentes
  • Connect e segurança recebem melhorias úteis de governança
  • o upgrade continua exigindo leitura cuidadosa da documentação

Não é uma release construída só para dizer que "tem novidades".

Ela mexe em pontos que aparecem em produção: estabilidade, coordenação de consumo, governança de configuração, observabilidade e previsibilidade operacional.

Para quem usa Kafka de forma mais séria, isso é o tipo de release que vale estudar antes de atualizar e vale entender antes de adotar novos recursos por impulso.

Meu olhar aqui é o de alguém de backend que gosta bastante de Kafka e acompanha de perto o impacto dessas mudanças na aplicação e na operação do dia a dia. Não é um texto escrito do ponto de vista de especialista em infraestrutura pesada, e sim de quem precisa entender o que a release muda de verdade para construir e evoluir sistemas.

Se você já testou a 4.2.0, está avaliando upgrade ou enxerga impactos diferentes no seu cenário, vale deixar um comentário. Esse tipo de troca costuma revelar muito mais sobre a versão do que a lista bruta de features.

Referências oficiais

Apache Kafka: