Bom pessoal, no nosso vídeo anterior, a gente falou sobre Saga utilizando um orquestrador. Ou seja, esse cara aqui galera, que vocês tem que entender, tudo isso que está rodando aqui, normalmente ele vai ser um serviço separado. Normalmente isso aqui é um orquestrador ou um mediador. Normalmente isso aqui é um orquestrador ou um mediador. Então ele utilizando nesse caso aqui eventos e esses eventos acabam mandando informações para tópicos. Agora um ponto importante que eu tenho que falar é que não necessariamente para que uma saga funcione dessa forma, isso tem que rolar através de filas. Isso aqui, por exemplo, tudo isso poderia acontecer via REST também. Qual que é o problema de você trabalhar com REST nesses casos? É que trabalhando com REST, imagina que na hora que eu mando a informação aqui para o serviço número 3, esse serviço número 3 está fora do ar. Aí essa saga vai ter que fazer o quê? Retentativas, e ainda está fora do ar. Então você vai ter que ter, ainda assim, mecanismos de retry, de exponential backoff, ou seja seja ele manda e tenta depois ele tenta depois de dois segundos depois de quatro depois de oito depois de 16 32 depois de um minuto depois de um dia e etc então você começa a perceber que é mais uma complexidade que você tem em relação às políticas de retry aqui. Quando você está trabalhando com filas, esse nível de problema você não vai ter, porque você garante a resiliência através das filas. Por outro lado, sempre você vai ter uma segunda coisa que vai poder acontecer, que é o seguinte, quando ele tenta compensar, dá um erro na compensação. E daí você não vai ter a compensação da compensação. Então, o que a gente faz nesse caso aqui? Quando um erro na compensação acontece, vamos imaginar que ele vai dar um erro aqui nessa compensação, você também pode fazer o seguinte, você pode criar um novo tópico, tá? Aqui, esse tópico é um tópico apenas de errors. E caso um erro aconteça, o que você vai fazer? Você manda a informação para esse tópico de erro, manda a informação para esse tópico de erro e depois você pode ter um sistema que fica analisando esses caras e reiniciando as operações ou você pode ter alguém manualmente que vai ficar olhando essa informação aqui e falando poxa esse erro foi por conta desse caso, né? Vamos arrumar e mandar isso aqui para execução de novo, entendeu? Então, isso também pode acontecer. Qualquer sistema pode ter erro, né? Então, aí, nesse caso, o interessante sempre é, dê um erro, você joga isso para um local onde você pode armazenar todos os erros para você analisar caso a caso e para que nenhuma transação seja deixada para trás. Então, isso aí é importantíssimo você levar em consideração. Então, quando você trabalha com comunicação síncrona, via REST, via GRPC, via GraphQL, não interessa o que vai acontecer. Você pode ter erro, inclusive, ali na rede. Você pode ter com o serviço que está fazendo o deploy. Pode ter diversas informações que você perde e você tem que ficar fazendo o retry. Agora, se você trabalha com filas, você vai estar mais protegido. Por outro lado, existe a complexidade de você trabalhar com filas também. E também existe sempre o caso de quando uma compensação também não dá certo. Porque se não dá certo a operação, ok, você compensa. Agora, se a compensação dá erro, você vai ter que guardar esses erros, analisar e resolver. Beleza? Então, essa que é a ideia de compensação e gerenciamento de erros.