JSON parece a escolha mais natural para eventos.

Todo mundo lê. Todo mundo escreve. Todo mundo entende.

E é exatamente aí que mora o risco.

No post anterior, falamos que evento não deveria vazar implementação interna. Aqui o problema fica ainda mais concreto: quando esse evento circula como JSON puro, sem controle formal de contrato, pequenas mudanças podem se espalhar pelo sistema como falhas difíceis de perceber.

O cenário que quase sempre começa "sem problema nenhum"

O sistema está em produção.

Um serviço publica eventos em Kafka. Vários consumidores leem o mesmo tópico. Tudo parece estável.

Então alguém faz uma mudança pequena no payload:

  • remove um campo que parecia opcional
  • renomeia um atributo para combinar com o padrão novo do time
  • troca o formato de um valor sem considerar todos os consumidores

O deploy sobe sem alarde.

Mas depois começam os efeitos colaterais.

Um consumidor quebra porque esperava exatamente aquele campo. Outro continua rodando, mas passa a ignorar parte dos dados. Um terceiro persiste informação incompleta sem erro explícito.

Esse é um dos problemas mais traiçoeiros em arquitetura orientada a eventos: nem toda quebra é barulhenta.

Por que JSON parece tão confortável

JSON é flexível porque não impõe um contrato forte por si só.

Ele descreve estrutura, mas não garante significado, compatibilidade nem evolução segura.

Se o produtor começa a enviar um campo novo, remover outro ou mudar um tipo, nada no formato JSON impede isso.

Na prática, o combinado entre produtor e consumidor vira um acordo implícito.

E acordo implícito em sistema distribuído costuma durar até o próximo deploy.

O problema real não é o JSON. É o JSON sem controle.

Quando o payload evolui sem versionamento e sem regra clara de compatibilidade, cada consumidor passa a depender da própria interpretação do evento.

Isso cria um cenário comum em produção:

  • o produtor evolui rápido
  • os consumidores assumem uma estrutura fixa
  • campos opcionais viram obrigatórios sem ninguém perceber
  • atributos removidos continuam sendo usados em algum ponto escondido do sistema

Como vários serviços podem consumir o mesmo tópico, o impacto também fica fragmentado.

Um falha na hora. Outro só produz dado inconsistente. Outro continua "funcionando" até chegar um caso de negócio mais específico.

Em muitos times, o consumer ainda usa configurações como ignoreUnknown para não quebrar quando campos novos aparecem no JSON.

Isso reduz atrito em mudanças aditivas, mas também pode mascarar a perda de controle sobre o contrato.

O sistema para de falhar alto e passa a falhar silenciosamente.

Esse tipo de divergência aumenta muito o tempo de diagnóstico.

O impacto aparece depois, e por isso custa mais

Os efeitos mais comuns são bem conhecidos por quem já operou Kafka em produção:

  • quebra silenciosa de consumidores
  • inconsistência entre serviços que leram o mesmo evento
  • bugs difíceis de reproduzir
  • rollback de emergência ou retrabalho para reconstruir compatibilidade

O mais perigoso é quando ninguém percebe na borda técnica.

O consumer continua de pé. O tópico continua fluindo. O lag parece normal.

Mas o significado do dado já se perdeu no caminho.

Como reduzir esse risco mesmo continuando com JSON

Se o time vai usar JSON, ele precisa tratar o payload como contrato explícito.

Isso significa:

  • definir claramente a estrutura esperada do evento
  • evitar mudanças destrutivas em campos já publicados
  • planejar como o payload vai evoluir ao longo do tempo
  • versionar eventos quando houver mudança incompatível

JSON pode continuar sendo o formato.

O que não pode continuar informal é a evolução desse contrato.

O ponto que separa flexibilidade de fragilidade

Flexibilidade sem controle parece velocidade no começo.

Depois vira risco operacional.

Em sistemas distribuídos, especialmente quando vários serviços consomem os mesmos eventos, contrato claro não é burocracia. É proteção contra quebra silenciosa.

Se o payload pode mudar a qualquer momento e ninguém sabe exatamente o que continua válido, o problema não está no Kafka.

Está no fato de o sistema ainda não tratar schema como parte da arquitetura.