Event-driven architecture

Ações em um domínio precisam disparar efeitos em outros — notificar sistemas externos, atualizar estoque, enviar webhooks — sem acoplar quem produz a quem consome.

Publicar eventos “depois” de salvar o estado abre uma janela em que um dos dois se perde. Mensageria mal aplicada troca acoplamento visível por acoplamento invisível.

Chamada síncrona

O chamador precisa da resposta para continuar e a dependência é estável.

Eventos com outbox transacional

O efeito pode ser assíncrono, mas não pode ser perdido.

Fila de tarefas simples

Trabalho pesado ou lento sem múltiplos consumidores.

• Desacoplamento e resiliência versus consistência eventual e depuração mais difícil.
• Outbox garante atomicidade entre estado e evento, ao custo de uma tabela e um despachante a operar.
• Consumidores precisam ser idempotentes: entregas duplicadas são normais.

Usar eventos quando há múltiplos interessados ou quando o efeito pode atrasar mas não pode falhar silenciosamente — sempre com outbox, idempotência no consumidor e rastreabilidade de entrega.

• Cada evento vira contrato: versionamento e catálogo de eventos passam a ser necessários.
• Observabilidade de filas (atraso, falhas, reprocesso) deixa de ser opcional.

• Mensageria resolve acoplamento temporal, não acoplamento de domínio.
• Se um evento pode ser perdido, ele não é um evento de negócio — é uma esperança.