Em sistemas distribuídos, o problema quase nunca começa no broker.

Ele começa quando o sistema cresce, os eventos passam a ser consumidos por vários serviços e o payload muda sem que exista uma definição clara do que aquele dado deveria continuar significando.

Um time renomeia um campo. Outro remove um atributo que parecia sobrando. Um terceiro muda o formato de um valor para atender uma necessidade interna.

O deploy passa. O tópico continua fluindo. Mas algum consumidor quebra, outro passa a ignorar parte do evento e outro segue processando dados com interpretação errada.

Coordenar isso entre vários serviços vira um desgaste constante.

No post sobre evento como contrato, a ideia central era separar integração de detalhe interno. Aqui, esse raciocínio fica mais concreto: schema é a parte formal desse contrato.

É nesse ponto que schema deixa de parecer detalhe e passa a ser parte do desenho da integração.

O que é schema em eventos

Schema é a definição formal da estrutura de um evento.

Ele descreve quais campos existem, quais tipos são esperados, o que é obrigatório, o que é opcional e quais regras aquele payload precisa respeitar.

Na prática, schema funciona como o contrato de dados entre quem publica e quem consome.

Sem isso, a estrutura do evento fica implícita. O produtor "acha" que está publicando uma coisa. O consumidor "acha" que está lendo a mesma coisa.

Enquanto ambos fazem a mesma leitura informal do payload, parece funcionar.

No post sobre JSON em eventos, esse risco apareceu justamente pelo lado da flexibilidade: quando tudo é informal, pequenas mudanças parecem inocentes até quebrar alguém em produção.

Quando o sistema evolui, essa informalidade cobra a conta.

O que acontece quando não existe schema

Sem schema, o evento continua existindo, mas o contrato fica invisível.

Isso normalmente traz três problemas de produção:

  • não existe validação real antes do evento circular
  • mudanças de payload acontecem sem controle claro de compatibilidade
  • dependências entre produtores e consumidores ficam espalhadas e difíceis de mapear

O efeito mais perigoso nem sempre é a falha explícita.

Muitas vezes o consumidor não cai. Ele apenas passa a interpretar o dado de forma incompleta, ignora um campo relevante ou grava informação inconsistente.

Esse é o tipo de incidente que custa caro porque aparece depois, longe do deploy que causou a quebra. É a mesma lógica de falha tardia que apareceu no post sobre perda lógica no consumer: o sistema parece de pé, mas o significado do processamento já se perdeu.

Por que schema importa de verdade

Quando o evento tem um schema explícito, o payload deixa de ser um JSON "mais ou menos conhecido" e passa a ser um contrato verificável.

Isso muda bastante a operação do sistema.

Primeiro, existe validação.

O produtor deixa de publicar qualquer estrutura por acidente, e o consumidor deixa de depender apenas de suposições informais sobre o formato recebido.

Segundo, a evolução fica mais controlada.

Adicionar um campo opcional é diferente de remover um campo usado por vários consumidores. Mudar um tipo não é a mesma coisa que enriquecer o evento de forma compatível. Com schema, essa diferença deixa de ser opinião e passa a fazer parte do contrato.

Terceiro, a integração fica mais segura.

Quando vários consumidores dependem do mesmo evento, o schema ajuda a reduzir quebras silenciosas e dá previsibilidade para mudanças no payload. Isso é especialmente importante quando o evento já deixou de ser consumo isolado e virou peça central de integração, como discutimos no post sobre DTO vs implementação.

Em outras palavras: ele não impede a evolução. Ele cria um jeito mais seguro de evoluir.

Boas práticas para não transformar evento em improviso

Algumas decisões ajudam bastante:

  • definir o schema como parte do design do evento, e não como ajuste posterior
  • tratar eventos como contratos versionados, especialmente quando a evolução puder afetar consumidores existentes
  • evitar mudanças destrutivas em payloads já publicados, porque o custo quase sempre aparece fora do serviço produtor

Esse cuidado é importante porque evento em produção não pertence só a quem publica.

Depois que ele vira integração entre serviços, ele passa a ter consumidores, dependências e impacto operacional distribuído. Sem isso, o time cai facilmente no cenário descrito no post sobre JSON flexível: o payload continua circulando, mas ninguém sabe ao certo o que ainda é compatível.

O ponto que vale fixar

Sistemas distribuídos exigem contratos claros.

Schema não é burocracia documental. É segurança para integrar serviços sem transformar cada mudança de payload em aposta.

Se o seu evento precisa evoluir, ótimo. Ele provavelmente vai evoluir mesmo.

Mas evoluir sem contrato formal é o caminho mais curto para quebrar consumidores sem perceber.

Tratar schema como parte da arquitetura é o que prepara o terreno para a próxima conversa importante: como evoluir esse contrato sem paralisar o sistema.