System Design/02 - Componentes/Background Jobs2 min
Event-Driven
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
O trabalho é disparado por algo que aconteceu, não pelo relógio. O produtor emite um evento; um ou mais consumidores reagem.
upload concluído → evento → transcodificar
→ gerar thumbnail
→ notificar seguidores
Evento vs comando
Distinção que muda o acoplamento:
| Comando | Evento | |
|---|---|---|
| Semântica | "faça X" | "X aconteceu" |
| Destinatário | Um, conhecido | N, desconhecidos |
| Acoplamento | Produtor conhece consumidor | Produtor não sabe quem escuta |
| Nome | Imperativo (EnviarEmail) |
Passado (PedidoCriado) |
Eventos permitem adicionar consumidores sem tocar no produtor — é o que dá extensibilidade ao modelo.
Notificação vs event-carried state
- Notificação magra: o evento carrega só o ID. O consumidor busca o resto. Simples, e gera carga de leitura no produtor.
- Event-carried state transfer: o evento carrega o estado necessário. O consumidor não precisa consultar ninguém — ao custo de eventos maiores e dado potencialmente obsoleto.
Trade-offs
O ganho é desacoplamento e extensibilidade. O custo é que o fluxo deixa de ser legível no código: não existe um lugar onde se veja "o que acontece quando um pedido é criado". A resposta está espalhada entre consumidores, e só o tracing distribuído reconstrói o quadro.
Ordem e duplicidade voltam a ser problema seu (Idempotent Operations). Consistência vira eventual: entre o evento e o processamento, o sistema está em estado intermediário observável.
Há também o risco de cascata de eventos — um consumidor emite outro evento, que dispara outro, e um ciclo pode se formar sem que ninguém tenha desenhado isso.
E o oposto do acoplamento de código: passa a existir acoplamento de schema. Mudar o formato do evento quebra consumidores que você não sabe que existem — daí a importância de versionar eventos e manter compatibilidade.
Exemplo prático
PedidoConfirmado é publicado uma vez e consumido por quatro serviços: estoque reserva, faturamento emite nota, logística agenda coleta, e marketing registra a conversão.
O serviço de pedidos não conhece nenhum dos quatro. Adicionar um quinto — antifraude, digamos — não exige alterar nem redeployar o produtor.
O preço: se faturamento falha, o pedido está confirmado e sem nota. O sistema precisa de retry, DLQ e um jeito de reconciliar — trabalho que num monolito transacional o COMMIT fazia de graça.
Relacionado
Parte de Background Jobs · roadmap.sh/system-design