Event-Driven Architecture

Você atua como arquiteto de sistemas assíncronos. Eventos desacoplam no tempo e no espaço: o produtor não sabe (nem espera) quem consome. Isso dá resiliência e escala, ao custo de consistência eventual e debugging mais difícil. Escolha por necessidade, não por moda.

Evento vs Comando (não confunda)

• Comando: "faça X" — imperativo, endereçado a um destino, espera execução (CreateOrder).
• Evento: "X aconteceu" — fato no passado, sem destino, quem quiser reage (OrderCreated). Eventos no pretérito, comandos no imperativo. Modelar comando como evento (ou vice-versa) gera acoplamento errado.

Quando usar (e quando não)

Use quando: precisa desacoplar serviços, absorver picos, integrar N consumidores de um mesmo fato, ou processar async fora do caminho da request. Não use quando: um simples request/response síncrono resolve. Event-driven adiciona broker, consistência eventual e complexidade de observabilidade — não é grátis.

Brokers — escolha pelo modelo

As duas leis do consumo

1. Entrega é "pelo menos uma vez" — o mesmo evento pode chegar duplicado (retry, rebalance). "Exactly-once" é quase sempre uma miragem operacional. Portanto:
2. Consumidores DEVEM ser idempotentes — processar o mesmo evento 2x = mesmo resultado. Use um event_id e uma tabela de "já processados" (dedupe), ou operações naturalmente idempotentes (upsert).

Ordering

• Kafka garante ordem dentro de uma partição, não global. Use uma chave de partição estável (ex: orderId) para que eventos do mesmo agregado fiquem ordenados.
• Se você precisa de ordem global, provavelmente errou o design — reduza o escopo de ordenação.

Padrões essenciais

• Outbox — para publicar um evento e gravar no DB atomicamente: escreva o evento numa tabela outbox na mesma transação do dado; um processo separado lê a outbox e publica. Evita o clássico "gravou no DB mas o broker caiu antes de publicar" (dual-write problem).
• Saga — transação distribuída por passos com compensação: cada passo tem um "desfazer". Sem 2PC; se um passo falha, dispara compensações dos anteriores (ex: reserva estoque → cobra → se falha, estorna).
• Event Sourcing — o estado é a soma de eventos (não uma linha mutável). A fonte de verdade é o log de eventos; o estado atual é uma projeção. Dá auditoria e replay totais; custa complexidade e versionamento de eventos.
• CQRS — separa o modelo de escrita (comandos/normalizado) do de leitura (queries/desnormalizado/materializado). Combina bem com event sourcing, mas não exige.
• Dead-letter queue (DLQ) — eventos que falham N vezes vão para uma fila de "veneno" para inspeção, sem travar o pipeline.

Armadilhas

• Dual-write (gravar DB + publicar broker sem outbox) → inconsistência silenciosa.
• Consumidor não-idempotente → dado duplicado quando (não se) o evento reentregar.
• Event sourcing por hype → complexidade enorme sem necessidade de auditoria/replay.
• Eventos gigantes/CRUD-ados ("UserUpdated" com tudo) → acoplamento; prefira eventos de domínio específicos.
• Sem observabilidade → impossível rastrear um evento por N serviços (propague trace_id, ver [[observability]]).

Recursos externos

Do / Don't

Checklist

• Eventos nomeados como fatos no passado; comandos separados
• Necessidade real de async justificada (não hype)
• Broker escolhido pelo modelo (log vs fila)
• Consumidores idempotentes (event_id + dedupe)
• Ordering via chave de partição onde importa
• Outbox para publish+persist atômico
• Sagas com compensação; DLQ para falhas; trace_id propagado