Event-driven
TLDR
Event-driven significa: em vez de um sistema chamar o outro e esperar a resposta na hora, um sistema publica um evento (ex.: “pedido criado”) e outros reagem quando puderem. Isso desacopla (menos dependência direta) e pode deixar algumas jornadas mais rápidas, mas o dado pode “aparecer depois” em algum lugar. Saber se um fluxo é chamada na hora (síncrono) ou por eventos (assíncrono) ajuda a definir o que pode ser prometido “na hora” e o que pode ser “em instantes”.
Por que isso importa
Não prometer “atualização na hora em todo lugar” se o fluxo é por eventos — pode haver atraso de segundos ou minutos. Entender por que algumas telas atualizam na hora e outras “em instantes” evita conflito de expectativa com usuário e negócio.
Conceito (em linguagem simples)
- Chamada na hora (síncrono): O sistema A pede algo ao B e espera a resposta para continuar. O usuário espera o resultado dessa cadeia.
- Por eventos (assíncrono): O sistema A publica “aconteceu X”; B (e outros) consomem quando puderem. O usuário pode ver uma confirmação imediata e o restante “propagar” depois.
Vale perguntar: essa jornada é chamada na hora (síncrona) ou por eventos? Onde o usuário precisa ver na hora e onde pode ser “em instantes”?
Conclusão
Saber se o fluxo é por eventos ou por chamada direta evita prometer “na hora” onde a arquitetura entrega “em instantes”.