Schema interno de eventos sem acoplamento acidental

O problema

Evento interno costuma começar assim:

• “vamos publicar porque outros módulos precisam reagir”

Até aí, tudo bem.

O problema aparece quando o evento vira:

• snapshot completo da entidade
• payload enorme com campos que ninguém sabe se são contrato
• reflexo da tabela atual

Nesse ponto, você não tem evento saudável.

Você tem acoplamento distribuído.

Modelo mental

Evento bom normalmente responde:

• o que aconteceu?
• com quem aconteceu?
• o que um consumidor razoável precisa saber para reagir?

Ele não precisa carregar tudo o que existe no agregado.

Quanto mais o schema parece um dump, mais fácil fica para cada consumidor puxar uma dependência acidental.

Exemplo simples

Imagine um evento de ativação de assinatura.

Uma versão melhor pode ser algo como:

• SubscriptionActivated
• subscriptionId
• accountId
• activatedAt
• talvez planTier

Uma versão pior parece:

• todos os campos da assinatura
• todos os dados de billing
• preferências de UI
• metadata solta
• flags herdadas de outros fluxos

No segundo caso, qualquer ajuste interno começa a ter cara de breaking change informal.

O erro comum

O erro comum é dizer:

“manda tudo porque aí ninguém precisa pedir depois”

Isso resolve o presente e piora o futuro.

Você ganha:

• consumidores lendo campo que nunca deveria ter sido contrato
• dificuldade de remover dado
• mudança simples virando migração ampla
• vazamento de semântica interna entre domínios

Outro erro comum é nomear evento como ação técnica, não como fato.

UserSyncPayloadReady costuma dizer menos do que UserEmailChanged, por exemplo.

O que normalmente ajuda

Schema interno melhor costuma nascer de algumas escolhas:

• nomear evento como fato de domínio ou fato operacional relevante
• publicar só o subconjunto que um consumidor razoável precisaria
• separar metadata técnica do dado semântico
• tratar evolução de schema como contrato, não como detalhe de implementação

Também ajuda perguntar:

• se ninguém conhecesse minha tabela, esse evento ainda faria sentido?

Se a resposta for “não”, provavelmente ele está acoplado demais ao modelo atual.

Como um senior pensa

Quem já sofreu com pub/sub bagunçado costuma perguntar:

• este evento existe para quê?
• estou comunicando fato ou transportando estrutura?
• quais campos são realmente estáveis?
• como isso evolui sem prender todos os consumidores na forma atual?

Essas perguntas evitam que evento interno vire RPC disfarçado ou dump com fan-out.

Ângulo de entrevista

Esse tema aparece em backend, sistemas orientados a eventos, modularização e integração interna.

O entrevistador quer ver se você entende:

• que evento é contrato
• que payload demais aumenta acoplamento invisível
• que schema de evento precisa ser orientado ao fato que aconteceu

Resposta forte costuma soar assim:

“Eu tentaria publicar eventos como fatos claros e com payload mínimo suficiente. Se o evento virar dump de entidade, cada consumidor depende de detalhe acidental e o sistema perde liberdade para evoluir.”

Takeaway direto

Evento interno bom não carrega tudo o que o produtor sabe.

Carrega só o que a conversa realmente precisa dizer.