Artigo sensacional, @andersonlimadev! O foco em correção e o overview sobre Ledger e Sagas ficaram extremamente didáticos.
Queria fazer uma observação sobre o Pilar 2 (Idempotência) que me chamou a atenção no exemplo de código:
Se olharmos estritamente para o trecho:
const transferId = crypto.randomUUID();
Existe um detalhe crucial de System Design / Frontend aqui. Se o crypto.randomUUID() for executado dentro da função de clique do botão sem nenhum controle de estado prévio, a idempotência vai falhar se o usuário clicar manualmente duas vezes seguidas por ansiedade (caso o botão não seja desabilitado instantaneamente). Cada clique geraria um UUID, criando uma intenção "nova" para o backend e gerando a duplicidade.
Para funcionar 100% no cenário de "clique duplo do usuário", a estratégia de ciclo de vida dessa chave precisa ser bem definida:
- Gerada na montagem do formulário: O UUID deve ser gerado no momento em que a tela/modal de transferência carrega e ser mantido no estado da aplicação.
- Reutilizada em retries: Se a rede der timeout (ou o usuário clicar de novo na mesma tela), o frontend deve retransmitir exatamente o mesmo UUID gerado inicialmente.
- Resetada após o sucesso: O identificador só muda quando a operação conclui com sucesso ou quando o usuário cancela e abre uma nova intenção de transferência.
Para retries automáticos via bibliotecas (como Axios ou React Query), o comportamento já costuma reutilizar o mesmo payload/headers perfeitamente, mas para ações humanas repetidas na UI, esse controle de estado no cliente é a linha que salva o sistema.