Como sistemas desacoplados conversam sem criar um nó?

Pense no fluxo de um e-commerce no momento em que um pedido é confirmado: o estoque precisa baixar, a nota fiscal precisa ser emitida, o e-mail precisa sair, a logística precisa ser acionada, o financeiro precisa registrar. Cinco sistemas interessados no mesmo fato.

Na integração tradicional, o serviço de pedidos chama um por um, espera cada resposta e trata cada falha. A cada novo interessado, o código do pedido cresce. O serviço que deveria cuidar de pedidos vira um maestro sobrecarregado que conhece todo mundo.

A arquitetura orientada a eventos (Event-Driven Architecture, ou EDA) inverte essa lógica com uma ideia simples: quem faz, anuncia; quem se interessa, escuta.

O mecanismo em três peças

1. Produtor: o serviço de pedidos publica um evento, um fato imutável do passado: "PedidoConfirmado #4193".
2. Broker: uma plataforma de mensageria (Kafka, RabbitMQ, SNS/SQS e afins) recebe e distribui o evento com durabilidade.
3. Consumidores: estoque, fiscal, e-mail, logística e financeiro escutam o evento e reagem, cada um no seu ritmo.

O ganho estrutural: o serviço de pedidos não conhece nenhum dos cinco. Amanhã, quando o time de dados quiser alimentar um dashboard em tempo real, é só criar um novo consumidor. Zero mudança em quem publica. É o desacoplamento que permite que times e sistemas evoluam de forma independente, exatamente a promessa dos microsserviços bem feitos.

Evento não é tudo igual: os três padrões

Martin Fowler alerta que "event-driven" virou um guarda-chuva confuso e separa os padrões principais (What do you mean by "Event-Driven"?):

• Event Notification: o evento só avisa que algo aconteceu, com o mínimo de dados. Quem precisa de detalhes, busca. Simples, mas cria dependência de consulta.
• Event-Carried State Transfer: o evento carrega os dados relevantes ("PedidoConfirmado" já leva itens, valores, endereço). Consumidores não precisam voltar na fonte, ao custo de eventos maiores e duplicação de dado.
• Event Sourcing: o log de eventos vira a fonte da verdade: o estado atual é a soma de tudo que aconteceu. Poderoso para auditoria e reconstrução, e significativamente mais complexo de operar.

A maioria dos sistemas reais combina os dois primeiros. Event Sourcing é ferramenta específica, não padrão de fábrica.

O preço da mágica

EDA não é almoço grátis, e é aqui que muitos projetos se machucam:

• Consistência eventual: entre o evento sair e todos reagirem, o mundo fica temporariamente "desalinhado". O negócio precisa tolerar isso, e nem todo fluxo tolera.
• Rastreabilidade: o fluxo que era uma pilha de chamadas vira uma cascata de eventos. Sem correlação de IDs e bom tracing distribuído, debugar vira arqueologia.
• Duplicatas e ordem: brokers entregam "pelo menos uma vez" na maioria das configurações. Consumidores precisam ser idempotentes, e ordem global raramente é garantida.
• Governança de contratos: o schema do evento é uma API pública. Mudou sem versionar, quebrou consumidores silenciosamente. É a decisão nº 3 da nossa lista de arrependimentos em outra roupa.

Quando EDA compensa (e quando não)

Compensa: fluxos com vários interessados no mesmo fato, picos de carga que pedem amortecimento (a fila absorve), integrações entre domínios e times diferentes, necessidade real de reagir em tempo quase real.

Não compensa: consultas do tipo pergunta-resposta (uma API síncrona resolve melhor), fluxos que exigem consistência forte imediata, e sistemas pequenos onde uma chamada de função dentro de um monolito modular faz o mesmo com um décimo da complexidade.

A regra que usamos em consultoria: evento para fatos que interessam a muitos; chamada direta para perguntas que interessam a um.

Desenhando o fluxo certo

Adotar eventos é menos sobre escolher o broker e mais sobre desenhar bem os fatos do negócio: o que é um evento, o que ele carrega, quem é dono de cada contrato e como versões evoluem. Errar esse desenho custa caro; acertar destrava times.

Esse desenho é parte do que entregamos no serviço de Arquitetura de Software: mapeamos os domínios, definimos contratos de eventos e o caminho de adoção gradual, sem big bang.

Curioso para saber se o seu fluxo pede eventos ou não? Descreva o cenário para a IA da Rabelo Digital, aqui no canto da tela. Ela aponta a direção em minutos. Sem formulário, sem espera.

---

Leia também

• Clean Architecture na prática
• Monolito vs Microsserviços: quando usar cada um
• 5 decisões arquiteturais que você vai se arrepender