# ADR-0006 — EDA seletiva com Transactional Outbox

**Status:** Accepted  
**Data:** 2026-07-14  
**Decisores:** Arquitetura de Software

---

## Contexto

Ingestão, indexação, IA e notificações precisam de fan-out e retry. Publicar eventos “na hora” sem coordenação com commit causa inconsistências inaceitáveis em produto auditável.

## Decisão

Adotar **Event-Driven Architecture seletiva** (ver doc EDA). Para eventos pós-mutação de negócio: padrão **Transactional Outbox** em PostgreSQL + publisher + consumidores idempotentes em Redis (MVP). Kafka/Redpanda apenas com ADR futuro e métricas.

## Alternativas consideradas

| Opção | Prós | Contras | Por que não |
|--------|------|---------|-------------|
| EDA em tudo | Desacoplamento máximo | Complexidade excessiva | Não para CRUD/auth |
| Dual write DB+queue | Simples na aparência | Inconsistência clássica | Proibido |
| Kafka dia 1 | Replay poderoso | Ops prematura | Adiar |
| Apenas cron polling | Simples | Latência, acoplamento | Complementar, não core |

## Consequências

### Positivas
- Atomicidade lógica commit↔evento.
- At-least-once com idempotência.
- Caminho de evolução para log de eventos.

### Negativas / riscos
- Publisher como componente crítico (métricas/alertas).
- Consistência eventual entre busca/grafo e OLTP.

### Follow-ups
- [ ] Desenhar tabela outbox e poller.
- [ ] Padronizar idempotency keys por consumidor.

## Referências

- [Event-Driven Architecture](../arquitetura/06-event-driven.md)