Bom pessoal, no vídeo anterior eu falei bastante aqui sobre ter essas duas diferenças aqui em relação aos bancos de dados. O grande ponto, a gente tem esse processo de sincronização. Agora, o ponto é, quando eu estou falando dessa sincronização, você vai perceber que a gente pode ter diversos mecanismos de sincronização. Alguns mecanismos são bem simples e alguns mecanismos são bem complexos. Então, é importante que você saiba qual mecanismo que você vai utilizar para que, intencionalmente, você saiba a melhor forma que você vai trabalhar no dia a dia aí de acordo com seu projeto galera e é sempre isso que eu quero trazer aqui pra vocês tá normalmente quando a gente vê muito conteúdo é que não trazem tanta profundidade você vai perceber que muitos vão parar por aqui. Ou muitos vão parar por aqui e nem vai falar dessa camada de domínio. O grande ponto é que essa pequena diferença aqui muda o jogo. Isso aqui muda o jogo completamente. E é por isso que eu quero trazer esses mecanismos de sincronização para você realmente estar ciente da onde que você está entrando ali no processo legal então vamos lá o primeiro mecanismo de sincronização que eu quero trazer aqui pra vocês ele é chamado de mensagem que os ou pub subsystem o que significa que você vai ter o seu comando que vai gravar os dados no banco de dados, mas esse comando também vai gerar um evento. Esse evento vai cair num tópico, esse consumidor vai ler os dados desse tópico e vai gravar esses dados no banco de dados de leitura. Legal? Isso aqui é interessante também porque porque esse consumidor quando ele leia esse evento ele consegue pegar esse evento aqui e gravar nesse banco de dados no melhor formato possível que ele quer conseguir um outro ponto também de uma vantagem de você trabalhar dessa forma, é que você não tem perigo de perder dados durante a sincronização. Por quê? Porque você está guardando essas informações num tópico. Então, se esse consumidor cair, quando ele subir, ele vai fazer o quê? Ler esses tópicos e gravar aqui nesse banco de dados. Então, aqui, ele permite que você tenha bastante resiliência tá porque a sua aplicação ela vai garantir que os dados não vão ser perdidos tá obviamente tá pra que você faça isso você também vai ter o que um response time aqui que vai ter que gerar um evento evento cai aqui passa pela rede aqui e passa pela rede aqui mas ainda assim é um mecanismo muito muito muito comum de isso acontecer bacana normalmente você vai utilizar esse caso quando você quer garantir resiliência e também você quer garantir tá de forma bem rápida que esse dado seja sincronizado, porque normalmente esses sistemas de mensageria, de PubSub, eles têm latências ali muito baixas, de 10 milissegundos ou até menos, tá? Então, por conta disso, você consegue manter essa sincronia com um delay não tão grande, tá? E mesmo assim você garante ali a segurança das suas mensagens. Agora, a gente tem um outro tipo de sincronização, que é chamado de Scheduled Synchronization Jobs. O que isso faz? Faz o seguinte, que você grave os dados no banco de dados, de tempos em tempos, tá? Eu tenho um job aqui que um consumidor vai ler no banco de dados, de tempos em tempos, eu tenho um job aqui que um consumidor vai ler esse banco de dados e vai guardar esses bancos de dados aqui na leitura. Ou seja, eu posso falar que a cada 10 segundos ele pega todos os dados que mudaram e joga tudo aqui de uma vez. Qual que é a vantagem de fazer isso no final das contas você não fica tá a todo tempo batendo nesse banco de dados e você não tem que ficar disparando eventos para trabalhar trabalhar dessa forma acaba sendo normalmente bem simples tá e eu não preciso de um mecanismo de fila para trabalhar a única coisa que eu preciso é de um job que rode pegue os dados e guarde tá então isso aqui é fácil tá fazer eu não preciso gastar com infraestrutura para ter um sistema de filas nada disso mas dá pra perceber que provavelmente o tempo de sincronização aqui vai ser maior porque enquanto isso aqui está acontecendo em tempo real isso aqui vai fazer a cada 10 segundos cada 15 segundos né e é por isso que você tem que saber o quão inconsistente você pode estar entre a base de leitura e de escrita. Às vezes, essa inconsistência, se eu ficar um minuto inconsistente, se eu ficar 30 segundos inconsistente, se eu ficar 100 milissegundos inconsistente, não tem problema. Imagina que você tem, por exemplo, um relatório que ele atualizado uma vez por dia e que não tem muito problema o que faz você bota um job roda uma vez por dia e tem um banco de dados de leitura aqui e não tem problema nenhum entendeu então eu não tenho a complexidade de trabalhar com filas aqui mas você vai perceber aqui no final do dia que esse job a ele mantém essa inconsistência mais longa tá aqui eu coloquei um consumer para dizer que o consumo executa o job tá mas se você não quiser ter essa confusão eu posso até colocar assim tá só pra você saber eu acho que vou até deixar assim pra ficar mais claro pra você como é que funciona então esse job de tempos em tempos eleda, pega os dados e sincroniza aqui. Bacana? E agora aqui também, galera, a gente tem um outro tipo de sincronização, que é chamado de Dual Write. Para esse vídeo não ficar grande, eu vou pausar ele aqui e a gente continua no próximo. Vamos nessa!