Radar Tech: migração de produtores Kafka com zero downtime — a state machine por tópico que domina o debate de eventos

Nas últimas 24 horas, uma das discussões mais comentadas de arquitetura em sistemas orientados a eventos voltou a girar em torno de um problema clássico e doloroso: como migrar produtores Kafka de um cluster para outro sem parar a produção, sem janela de manutenção e sem perder uma única mensagem. O estopim foi um engenheiro da WarpStream detalhando como construiu o sistema de migração automática de produtores da plataforma — tema que reuniu dezenas de comentários no Hacker News pela combinação rara de rigor técnico e aplicabilidade imediata.

O problema que todo mundo conhece

Um cluster Kafka raramente atende a um único time. Muitos serviços produzem e consomem o mesmo tópico, e migrar tudo "de uma vez" é receita para outage e perda de dados. Dividir a tarefa em três frentes — dados, consumidores e produtores — expõe o calcanhar de Aquiles: os produtores. Dados podem ser replicados sem perda e sem reordenar. Consumidores conseguem carregar os offsets de grupo e recomeçar exatamente de onde pararam. Já os produtores, se pausados, significam parar a escrita durável; um único produtor esquecido ainda gravando no cluster antigo pode custar dados para sempre.

A resposta madura passa por uma combinação de padrões que cabe em qualquer plataforma de eventos, independente do fornecedor: uma state machine por tópico, um proxy de encaminhamento de produce e um mecanismo de reversibilidade explícita.

A state machine por tópico

O ponto de partida é tratar cada tópico como uma unidade independente de migração, com quatro estados:

• REJECT — enquanto o destino replica os dados do fonte, qualquer escrita direta nele é recusada. Isso preserva a paridade de offset registro a registro.
• PROXY — os produtores trocam o bootstrap para o destino quando quiserem, no ritmo de cada time. O proxy recebe a escrita e a reencaminha de forma fiel ao cluster fonte. Cada time migra no seu tempo, sem coordenação sincronizada.
• MIGRATING — o corte em si. Os proxies param de encaminhar e respondem com erro retriável; os produtores seguram as escritas no buffer e tentam de novo. O control plane drena o lag de replicação a zero.
• COMPLETE — o destino passa a servir as escritas diretamente; o próxima retry do produtor é atendido pelo novo cluster.

Reversibilidade é parte do contrato: se o lag não zerar dentro do timeout, o tópico volta automaticamente ao estado PROXY e retoma o encaminhamento. O corte é uma porta que só se tranca quando a migração termina de verdade.

As garantias que fazem a diferença

O que separa uma migração bem-feita de um "torcer para dar certo" são quatro decisões sutis de arquitetura, todas replicáveis:

• Durabilidade antes de tudo. A replicação só pode ser desligada depois que todos os proxies confirmarem que pararam de encaminhar e drenaram as escritas em voo — só então o lag é medido a zero. Uma mensagem reconhecida ao produtor jamais pode ficar para trás no fonte.
• Lease de escrita em vez de confiança cega. Cada proxy tem uma permissão temporária de encaminhar que expira em segundos. Um proxy particionado, que não consiga renovar a lease, deixa de encaminhar sozinho — e respostas de escritas incertas viram erro retriável, nunca sucesso. Trocar perda de dado por duplicata ocasional é o trade-off correto.
• Medir lag em tempo, não em offset. Atrasar um milhão de registros pode ser segundos num tópico de alto tráfego ou uma semana num de baixo. O corte só inicia quando o descompasso, em segundos, cabe confortavelmente no timeout.
• Ajustar a latência antes do corte. Se o destino demora mais para reconhecer (ex.: armazenamento em objeto), o produtor precisa de buffers e in-flight maiores. Esperar o corte para descobrir isso é o pior momento possível — o proxy "modela" a latência do destino ainda na fase PROXY, e a regra de ouro é a lei de Little: throughput ≈ (requisições em voo × tamanho da requisição) / latência de ack.

O que isso ensina para a arquitetura

A migração de produtores Kafka com zero downtime não é um truque de uma ferramenta específica — é um padrão de design de sistema confiável: isolar a mudança por unidade (tópico), concentrar o controle num único ponto auditável (o proxy), e fazer o sistema defender a própria durabilidade (lease, dreno, rollback) em vez de depender de um operador atento ao dashboard.

Para quem produz no dia a dia, vale o lembrete: se o seu plano de migração de eventos depende de parar produtores, coordenar todos os times ao mesmo tempo ou "esperar o lag zerar olhando a tela", há uma versão mais segura dele — por tópico, reversível e com a durabilidade garantida por construção.

Recursos

• Artigo técnico original da WarpStream sobre automação de migração de produtores Kafka.
• Publicado na comunidade como um dos destaques de engenharia de sistemas orientados a eventos das últimas 24h.

Quer aprofundar? O prompt do marketplace desta semana transforma esse mesmo plano de migração em um ADR executável: você descreve o seu ambiente e a ferramenta de IA devolve um protocolo de corte por tópico, com critérios de aceite e checklist de rollback prontos para revisão.