Fala galera, vamos dar continuidade aqui e o encerramento de quando a gente está falando de uso de cache. Quando a gente está falando de cache, a gente não está querendo o que? A primeira coisa que a gente comentou aqui é, a gente quer diminuir a incidência de busca de dados no banco de dados. Ou seja, eu quero deixar o meu banco de dados resguardado e sem ter um alto consumo toda hora que a gente precisa de algum tipo de informação. Então, com isso, você diminui o número de chamadas e acaba deixando o seu banco de dados mais performático para a sua aplicação. Super interessante, super prudente da gente utilizar também. Outra coisa também que a gente pode utilizar é nas sessões de usuário. Guardar ali a sessão de usuário, ter aquela memória básica do que está rolando, vai deixar a sua aplicação também mais rápida, mais eficiente do que você guardar essa sessão de usuário em um banco de dados e ter que ficar voltando lá para buscar toda hora. Então também é outra estratégia super interessante para a gente. Outra coisa também que é muito importante, que a gente acaba utilizando bastante, é suporte a pico de tráfego. Ou seja, quando eu estou num momento onde eu tenho muito acesso àquele banco de dados, momento onde tenho muito acesso àquele banco de dados todo mundo sabe que a escala aplicação muito fácil em todo o banco de dados a gente consegue então o banco de dados é um pouco mais chatinho de você conseguir trabalhar com ele dá é a vazão que ele precisa ter ali de throughput então quando a gente usa é ela esquece a gente começa a diminuir um pouco a pancada que a gente dá no banco quando a gente está tendo um aumento de um pico a gente gente consegue deixar a aplicação responder em algum tempo que faça sentido. Então aqui a gente falou de cache de banco de dados, seção de usuário, como é que a gente melhora aqui também, e suporte a picos de ação, beleza? O Elastic Cache em geral é basicamente isso, a gente já abordou aqui todos os itens que a gente podia, tanto de Redis, assim por diante. E agora eu queria falar com vocês um pouco dos cuidados que a gente precisa ter. Não adianta só a gente sair implementando Elastic Cache, tá? O que eu olho no dia a dia? A gente acaba falhando em alguns pontos. Eu vou trazer aqui com vocês alguns do que eu já vi e que, cara, a gente faz isso direto. Vários lugares, quando eu falo a gente, é a gente e o meio de desenvolvimento, tá? Vários lugares, quando eu falo a gente, é a gente e o meio de desenvolvimento, tá? Um monte de lugares fazem isso, um monte de pessoas estão fazendo isso quando estão implementando cache. A primeira coisa é a sincronização. Você precisa se certificar que os dados que você está colocando no cache, que você está utilizando, eles estão com a melhor fonte possível. Eles não vão ser o dado mais quente, porque o dado mais quente vai estar no banco de dados, possivelmente. Mas são os melhores dados que você pode ter. Então, por exemplo, imagina o caso de consulta de saldo que eu falei. Não adianta eu trazer em cache a consulta de saldo de uma hora atrás, possivelmente. Pô, preciso trazer o cache de dois segundos, três segundos para trás, quatro segundos, Faz sentido? Pode ser. Essa é uma estratégia de cache que você tem que prestar atenção e ver quão sincronizado ele está o seu banco de dados e como que isso está representando para a sua funcionalidade. Vai depender muito da função que você tem, se você quer dar de experiência para o usuário e assim por diante. Mas não deixe o dado de cache ficar não sincronizado ou diferente. Se ele ficar diferente temporariamente e a sua aplicação permite isso, ou seja, a sua funcionalidade está aberta a esse tipo de debate, ok mas toma cuidado, tá bom? Usar o cache e acabar esquecendo que aquela informação não é a mais quente, às vezes pode te dar um trabalhão e levar para o usuário uma experiência um pouco errada. Outra coisa também é a invalidação de cache. Implementar ali uma estratégia mais robusta de validação, de quando o cache já mudou alguma coisa, ou seja, o dado já não é mais o mesmo, a gente precisa mudar, o dado andou, e a gente precisa alterar o cache, é super importante também. Então, se você precisar de um dado quente, que é aquele dado mesmo, tem que ser idêntico ao que está no banco de dados, numa troca de dados, você precisa implementar alguma coisa, pode ser que são o TTL, que é o Time to Live aqui, ou o Webhook, algum tipo de ouvinte que vai pegar esse dado que mudou e atualizar no seu cache ou atualizar os eventos ali no banco de dados, beleza? Então é importante a gente ter a consistência dos dados fechando a ponta aqui para a gente não tomar nenhum susto. Outra coisa é o tamanho e o gerenciamento do cache. Um erro que acontece muito, muito mesmo, é esse primeiro, overhead de memória. que acontece muito muito mesmo é esse primeiro overhead de memória o o elast cache ele vai usar memória vai torrar memória porque está tentando dar melhor experiência ali é de consulta e memória e com isso precisa ter uma máquina apropriada para isso você está preparado para ter um ambiente que consiga performar para isso porque eu vejo muita gente fazendo primeiro um colocar a uma máquina que não é ideal para o elast cache então você primeiro um colocar a uma máquina que não é a ideal para o eletrocast você vai colocar uma máquina para redes por exemplo que não é que vai suportar aquilo que se rodar uma outra coisa que também acontece muito é você colocar o redis na mesma máquina que você colocou a sua aplicação que vai acontecer sua aplicação está rodando começou a ter um pico ela começa a consumir memória seu rede vai Redis vai fazer o quê? Consumir a mesma memória. Então, você vai torrar a sua memória, vai tirar a memória da aplicação, a aplicação vai começar a topar porque o Redis consumiu tudo. Então, é interessante você deixar em lugares separados, não competir a memória de utilização, tanto no seu microserviço quanto bastante atenção nisso. Uma outra coisa também é a gente pensar em estratégias pra gente remover os itens antigos ou os itens que a gente não tá usando ali pra gente deixar a memória ali sempre limpa e usar uma memória de forma mais consciente não torrando tudo que pode dar problema pra gente também no futuro. Isso quando você tiver memória mais limitada, mas vou te falar, é bom fazer sempre, tá? Segurança também é outro ponto que eu vejo a galera errando muito. Você consegue usar cache? Consegue. Mas para usar cache, você tem que primeiro pensar em como que você vai deixar esse dado seguro, qual dado que você está deixando e qual camada você está deixando. Tem pessoas que estão levando cache para o front-end. Tem linguagens de front-end que permitem um tipo de cache ali por diante. linguagens de front-end que permitem um tipo de cache ali por diante. Se você colocar o cache no front-end, sei lá, o Next.js, sei que está permitindo, assim por diante. Não tem problema. Só toma cuidado para você ver o que você leva. Se forem dados que são críticos ou sensíveis, eu não acho que é uma boa ideia você levar para o pé do front, deixa mais para o back-end, trabalha isso em uma camada que está mais proteg mecanismo ali que consiga proteger esse dado de criptografia, etc. Tomando cuidado pra você não levar muita regra de negócio, nem regra mais parruda pra dentro do seu front-end que pode te trazer um outro problema no futuro de virar acabar um monolitão de micro front-end. Então, muito cuidado com isso também. Mas, ponto principal aqui, cuidado com dados sensíveis, beleza? Tem um monte de ponto que eu acabo colocando aqui de arquitetura para a gente tomar cuidado também, mas o principal é cuidado com o dado que você está deixando ali e como é que você está armazenando esse dado para ninguém ter acesso sem poder. E nem incluir coisas sem poder também. O acesso ao cache em específico, você tem que limitar também, olhar as permissões e assim por diante, tanto para ninguém incluir eventos nele, quanto para ninguém ler o que está acontecendo ali e ter informações privilegiadas de algum tipo de situação. Então, muito cuidado com o acesso ao cache também. Uma outra coisa que eu comentei com vocês durante o nosso papo aqui e que eu queria falar novamente. Isso aqui acontece muito também. Quando a gente desenha a aplicação, o pessoal esquece de abstrair os componentes de infra que a gente pode utilizar e entender o que acontece caso dê um erro em algum deles. Então, tem algumas especialidades de teste que a gente coloca de chaos, que você vai derrubando as aplicações para ver assim por diante, que podem te ajudar. Mas, de qualquer jeito, quando você está desenhando uma arquitetura de utilização de cache, você não pode ter dependência do cache. Lembra o que eu falei antes? O cache é para melhorar a experiência, para melhorar o seu sistema, para ter o dado mais rápido. Ele não pode quebrar ou travar a experiência. Muita gente acaba colocando cache e esquece de pensar no seguinte, o cache está para fazer o cache de dados entre o seu banco de dados quente e o seu serviço. Se ele está aqui para fazer o cache, se ele estiver fora, o que você vai fazer? Vai buscar no banco de dados. Você não precisa quebrar a aplicação, você não precisa quebrar a experiência, você simplesmente vai deixá-la mais lenta. Tem que pensar no graceful degradation aqui, para você continuar com a experiência funcionando, só que não com o cache. o cache não pode ser quem piora a experiência, ou vamos dar outro caso, guarda o sessão de usuário, o cache está fora, joga isso para algum banco de dados, trabalha com banco de dados, sempre tem que ter um banco de dados subjacente ali para você utilizar e assim por diante, então toma cuidado, protege a aplicação e pense em estratégias de Circuit Breaker para ele, estratégias de Graceful Degradation para você não destruir toda a experiência com a vontade de melhorar ela, tá bom? Então aqui é um outro ponto, tem que prestar muita atenção e eu vejo muita gente falhando, já peguei isso várias vezes e... cuidado, beleza? Outra coisa também é a complexidade de implementação. Meu, concorda que a partir do momento que você tá colocando o cache, imagina, você tinha lá um API que ela batia no banco de dados. Aí você vê aqui, colocou um cache. Você já ficou agora com três componentes. Tem a sua API, o cache e o banco de dados. Aí você vira e fala o seguinte, olha, para esse cache, eu quero implementar alguma estratégia aqui de derrubar a mensagem quando ela está saindo do... está ficando diferente do meu banco de dados e fazer uma mudança no meu Elastic Cache aqui, no meu Redis, que seja, toda vez que tiver alguma mudança de chave lá, valor, alguma coisa no meu banco de dados. Então, eu estou fazendo a alteração, já virou quatro componentes. Aí, o vídeo fala, beleza, nesse cenário, eu preciso fazer algum tipo de lógica, de Circuit Breaker, para quando o banco de dados estiver, quando o cache estiver fora, eu jogar a minha aplicação para o banco de dados. Então, eu estou colocando mais, não é outro componente, mas uma lógica aqui diferente de jogar de um lado para o outro. Se você parar para pensar, só isso tudo que eu comentei para você já virou um trabalho. Esquece que você tinha que funcionar para implementar. Só isso daqui já é um trabalho grande. Se você estiver colocando isso em ambientes muito complicados, não esquece de documentar, de fazer o mais simples possível, de buscar alternativas e ver se as coisas realmente fazem sentido, quando fazem sentido, para você também não deixar uma arquitetura extremamente complexa que depois ninguém mais consegue usar. E a lógica também ali, lembra que eu falei, por exemplo, o Rediz, ele permite uma porrada de estratégias. Se você tiver uma lógica errada de criação de mensagem dentro do Rediz e assim por diante, vai ser um diabo para entender aquilo também muito cuidado para você não trazer toda a sua inteligência para dentro do Redis de negócio usa o Redis para inteligência de cache o que for negócio deixa dentro da sua aplicação senão você vai confundir todo mundo também na hora de entender o que tem ali dentro beleza? então vamos tentar deixar menos complexo possível