Kafka em produção: quando a gestão do cluster vira o próprio problema

Em muitos projetos, o Kafka entra como “infra pronta”: sobe o cluster, cria tópicos e, nos primeiros meses, tudo parece estável. Com o crescimento de produtores, particionamento desalinhado com o domínio e consumidores com processamento lento, o time de plataforma passa a gastar mais tempo apagando incêndios do que evoluindo o produto.

Gargalos que aparecem na prática

Partições mal dimensionadas geram hotspots: um único broker recebe a maior parte do tráfego enquanto outros ficam ociosos. Retenção e tamanho de disco mal calibrados levam a I/O saturado e latência de produce/consume que “some” dos dashboards até estourar de vez.

Consumidores com max.poll.interval estourado causam rebalances em cascata; em times sem observabilidade forte, isso vira “intermitência inexplicável”. Já exactly-once mal compreendido em pipelines críticos pode mascarar duplicidade ou perda sob falha.

O que ajuda de verdade

Contratos claros entre times (schema, SLAs de lag, política de dead-letter), métricas por tópico/partição, playbooks de rebalance e decisões explícitas sobre retenção e compactação — não “o padrão do Helm chart”. Em consultoria, costumamos começar por um mapa de fluxos reais e só então ajustar cluster, clientes e monitoração.