Eu entendi perfeitamente sobre a aula, porém estou com uma coisa na cabeça... Todos os microservices precisam tratar erros assim? Pois oq eu achei estranho é fazer vários SAVE no banco do mesmo cara a cada passo.. isso não sobrecarrega o banco?
Solucionado
Eu entendi perfeitamente sobre a aula, porém estou com uma coisa na cabeça... Todos os microservices precisam tratar erros assim? Pois oq eu achei estranho é fazer vários SAVE no banco do mesmo cara a cada passo.. isso não sobrecarrega o banco?
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.