5.2. Modos de fluxo de dados: banco, serviços, workflows e eventos
Dados fluem por bancos, chamadas de serviço, workflows duráveis e mensagens; cada caminho tem seu problema de compatibilidade.
Resumo
- Via banco: dado escrito hoje é lido anos depois ("dado dura mais que código"). Cuidado com campos desconhecidos.
- REST e RPC: chamada de rede ≠ chamada local; pode falhar, demorar ou executar sem resposta. Use idempotência e versão de API.
- Execução durável (ex.: Temporal): workflow registra cada passo; após falha, retoma sem repetir efeitos. Exige código determinístico.
- Arquitetura orientada a eventos: produtor publica no broker; consumidores desacoplados, assíncronos, com buffer.
- Atores trocam mensagens assíncronas; em todos os modos, evolua com compatibilidade nos dois sentidos.
Perguntas-chave
responda de cabeça, depois abraPor que RPC que imita chamada local é enganoso?
Uma chamada de rede pode se perder, expirar sem saber se executou, ter latência variável e exigir serializar parâmetros; nada disso existe localmente.
O que é uma operação idempotente?
Executá-la duas vezes tem o mesmo efeito que uma; permite repetir com segurança após timeout (ex.: chave de idempotência num pagamento).
O que a execução durável garante?
Que um processo de vários passos (cobrar, reservar, enviar e-mail) chegue ao fim mesmo com falhas, sem repetir passos já concluídos.
Exercícios de fixação
0/5 respondidas1.
O cliente chama
POST /pagamentos, dá timeout e não sabe se o pagamento foi feito. Qual solução o capítulo indica?2.
Um fluxo "cobrar cartão → reservar estoque → enviar e-mail" precisa terminar mesmo se o servidor cair no meio. O que ajuda?
3.
Por que o código de um workflow durável precisa ser determinístico?
4.
O serviço de pedidos publica
PedidoCriado; estoque, faturamento e e-mail reagem quando puderem. Vantagem principal:5.
"Dados duram mais que código" significa que: