Sistemas event-driven sem folclore

Arquitetura event-driven ajuda quando o sistema precisa de baixo acoplamento, trabalho diferido ou fan-out para múltiplos consumidores. Ela prejudica quando os times tratam async como padrão e perdem de vista a visibilidade de falhas, o custo de replay e o fardo operacional do comportamento distribuído.

A pergunta útil não é "event-driven é mais moderno?", e sim "async reduz o custo total deste fluxo de trabalho?". Se a resposta for não, um design síncrono costuma ser mais seguro, mais barato e mais fácil de operar.

O ensaio do Martin Fowler sobre o que significa event-driven ainda é uma boa referência de enquadramento porque separa o estilo do hype. Em produção, porém, a pergunta importante não é o rótulo do padrão. É se você consegue arcar com o modelo de recuperação que vem junto com ele.

Sistemas event-driven reagem a fatos que já aconteceram: um pedido foi pago, um usuário se cadastrou, um registro mudou. Em vez de forçar todo o trabalho subsequente dentro de uma única requisição em linha, o sistema publica um evento e deixa os consumidores a jusante decidirem o que fazer em seguida.

Esse design desloca a pressão de um lugar para outro. Você não está mais projetando apenas comportamento. Está projetando também contratos, retries, idempotência, replay e ownership.

O trade-off não é arquitetura antiga versus nova. É controle direto versus acoplamento diferido.

Use síncrono quando a correção depende de uma resposta imediata. Use assíncrono quando o trabalho pode acontecer depois sem prejudicar o resultado do negócio.

Async é mais forte quando o problema de negócio se beneficia de separação no tempo ou na ownership.

Casos típicos:

• uma ação gera fan-out em várias reações independentes
• trabalho lento ou instável a jusante não deveria bloquear o usuário
• o tráfego é rajado e precisa de buffering
• o negócio se beneficia de um histórico durável de fatos de domínio
• múltiplos times precisam evoluir sem acoplamento forte de requisição

Exemplos:

• enviar um e-mail de confirmação após o cadastro
• atualizar analytics após o checkout
• sincronizar um índice de busca após mudanças de conteúdo
• disparar uma revisão antifraude após comportamento suspeito

Async fica caro quando o fluxo precisa de:

• correção imediata
• fronteiras transacionais estritas
• baixa ambiguidade sobre sucesso ou falha
• coordenação estreita entre consumidores de qualquer forma

Se um pagamento ou uma checagem de permissão precisa ser autoritativo no momento, um evento costuma ser a abstração errada.

Sistemas event-driven ainda podem ser fortemente acoplados:

• um consumidor depende de campos que o produtor pode remover
• uma mudança de schema quebra consumidores antigos
• um serviço a jusante se torna o dono oculto de uma regra de negócio
• produtores e consumidores renegociam contratos informalmente toda semana

Acoplamento fraco só existe quando os contratos são estáveis o suficiente para cada lado evoluir de forma independente.

Um barramento de eventos é transporte, não resolução. As perguntas difíceis continuam:

• como você sabe que um evento não foi processado?
• como você detecta processamento duplicado?
• como você se recupera após a queda de um consumidor?
• como você sabe se um consumidor está travado ou apenas lento?

Sem respostas para essas perguntas, async está escondendo risco em vez de gerenciá-lo.

Replay é um dos custos mais subestimados em sistemas event-driven.

O custo de replay aparece em:

• custo de computação para reprocessar histórico
• custo de coordenação para decidir o que reprocessar e quando
• custo de correção quando lógica antiga interage com estado novo

Replay deveria ser uma capacidade explícita, não uma palavra mágica em diagramas de arquitetura.

A mesma ideia aparece no padrão idempotent consumer: se replay e entrega duplicada são esperados, o contrato do consumidor precisa ser desenhado para isso, e não remendado depois.

Documente:

• quais eventos são replayáveis
• quais consumidores podem rodar de novo com segurança
• como efeitos colaterais duplicados são prevenidos
• como verificar o sucesso do replay

Sagas são úteis quando um processo de negócio atravessa múltiplos serviços e o rollback precisa ser explícito em vez de transacional.

Use uma saga quando:

• o fluxo é de longa duração
• cada passo tem um efeito colateral independente
• a compensação precisa ser modelada intencionalmente
• a conclusão eventual é aceitável

Não use uma saga só porque uma transação parece inconveniente. Ela continua sendo uma máquina de estados complexa, com seus próprios caminhos de falha e recuperação.

O texto do Chris Richardson sobre o padrão Saga é útil aqui porque deixa o trade explícito: sagas mantêm consistência entre serviços, mas trocam rollback automático por lógica compensatória que agora é sua responsabilidade.

Use este checklist antes de escolher arquitetura event-driven:

1. O chamador precisa de sucesso ou falha imediatos?
2. O trabalho a jusante pode acontecer depois sem prejudicar a correção?
3. O fluxo tem fan-out pesado o suficiente para justificar o desacoplamento?
4. Você consegue observar lag, falhas e retries com clareza?
5. Você tem consumidores idempotentes e um caminho seguro de replay?
6. Os contratos de evento têm regras de ownership e versionamento?
7. Uma requisição síncrona seria mais simples e mais barata de operar?

Se mais de duas respostas forem incertas, o sistema provavelmente não está pronto para async.

• defina eventos como fatos de negócio, não como payloads de transporte
• atribua ownership clara de schema
• torne os consumidores idempotentes antes de adicionar retries
• acompanhe lag, volume de dead-letter e taxa de falha
• documente os procedimentos de replay e compensação

Se você precisa da camada de duplicatas e retries na borda do sistema, leia Idempotência para webhooks. Se você precisa da camada de visibilidade operacional que torna sistemas async depuráveis, leia Observabilidade para engenheiros de produto. E se você está apostando em filas para todo problema, leia Filas não são bala de prata.