Kafka 4.2 Share Groups Quebram o Acoplamento Partição-Consumer

Kafka 4.2 marca Share Groups como production-ready e KIP-1150 (diskless topics) como production-ready seguindo aceitação da comunidade Apache em março de 2026. Equipes executando ML feature pipelines agora enfrentam escolhas arquitetônicas concretas: tiered storage, upgrades de protocolo de rebalanceamento, virtual clusters e diskless deployment. O deep dive da InfoQ por Viquar Khan mapeia a stack completa em termos acionáveis para platform engineers.

Tiered storage via KIP-405, production-ready desde Kafka 3.6, divide retenção em camadas local (broker block storage para dados quentes) e remota (S3, Azure Blob, GCS). O Remote Log Manager move assincrônamente segmentos de log para object storage; consumers lendo segmentos antigos buscam de cloud storage sem brokers mantendo-os localmente. Para equipes de ML com histórico de features de múltiplas semanas, armazenamento local cobre apenas a janela quente (1–7 dias) enquanto armazenamento remoto evita overhead de multiplicador de replication-factor porque cloud object stores tratam durabilidade. Resultado: redução de custo de armazenamento de 60–80%.

A armadilha de custo-visibilidade: quando armazenamento muda para cobranças por-requisição de cloud API, um único replay job pode disparar a fatura sem atribuição. Khan chama isso o problema do "economic operating system"—arquitetura exige governança ativa (políticas de replay cost-aware, aplicação de quota por consumer group). Equipes de ML executando backfills de features históricas devem implementar tagging de custo por-job antes de habilitar tiered storage.

O protocolo de rebalanceamento next-generation do KIP-848, production-ready em Kafka 4.0, elimina pausas stop-the-world durante pod autoscaling. Lógica de rebalanceamento movida para o broker com atribuição declarativa. Eventos de scale-up e scale-down não travem mais a consumer group—crítico para pipelines de online-learning onde consumers autoscale contra feature ingestion lag.

Share Groups (KIP-932, Kafka 4.2) quebram acoplamento partition-consumer. Múltiplos consumers puxam cooperativamente da mesma partição com per-record acknowledgment. O número de consumers pode exceder o número de partições. Para ML inference pipelines processando requisições de scoring independentes, isso habilita horizontal consumer scaling sem re-particionamento custoso. Discover Financial Services processou 4 milhões de registros de transação em 9 minutos para modelos de fraude e risco downstream após comprimir adoção de mudança de preços de seis meses para três semanas.

Virtual clusters fornecem limites estritos de tenant—namespaces de topic separados, quotas, controles de acesso—sem duplicação de infraestrutura. O tradeoff: complexidade operacional na camada de gerenciamento de virtual-cluster atualmente requer custom tooling.

Diskless Kafka permanece horizon-line. KIP-1150 (aceito em março de 2026) estabelece arquitetura: todos os dados em object storage, brokers stateless, leaderless design, batch-based writes (producer → broker buffer → object storage upload → offset assignment). Três propostas concorrentes convergiram em março de 2026. Aceitação é fundação; implementação em produção está pendente. O protótipo open-source da AutoMQ e o projeto Inkless da Aiven são as implementações executando mais próximas.

Playbook do arquiteto: habilitar tiered storage apenas após construir telemetria de cost-attribution; planejar migração KIP-848 antes de qualquer trabalho de Kubernetes autoscaling; avaliar Share Groups em Kafka 4.2 para inference job queues onde ordenação importa menos que horizontal scaling; tratar diskless topics como 2027 planning input, não 2026 target.