Aula03 Cap05 - Tratando erros na integração (DÚVIDA)

Não necessariamente todos tratarão erros assim. Nesse caso, por se tratar de um transação distribuída (depende de outros serviços), para não perder o estado de processamento da transação, criou-se um Enum para manter esse estado no banco de dados. Com isso, em caso de erro, sabe-se em que momento da transação o erro ocorreu, podendo ser reprocessado. Como explicado em algum momento da aula, caberia a uma classe de orquestração fazer o retry ou rollback, de acordo com o último status. Acredito que a sobrecarga do banco vai depender muito do case/problema que o sistema vai resolver e da situação em específico, mas obviamente, caso escale a ponto de impactar o próprio banco de dados, talvez seja o momento de repensar algumas decisões de design. Para isso existem outras formas de solucionar o problema de transação distribuída. No caso do exemplo, isso é feito de forma síncrona (design pattern Circuit Breaker) mas poderia ser resolvido de forma assíncrona (Ex. design pattern SAGA[1][2]).

[1] https://developers.redhat.com/blog/2018/10/01/patterns-for-distributed-transactions-within-a-microservices-architecture/ [2]https://microservices.io/patterns/data/saga.html

Muito interessante, vou ler sobre. Obrigado.