Caching: o que é e como funciona

Atualmente, quando utilizamos sistemas para gerenciar informações, necessitamos cada vez mais de dados precisos e rápidos, e com isso criamos um paradoxo entre quantidade x velocidade. 

Os usuários de sistemas buscam por informações mais rápidas para otimizar melhor o tempo de seus processos. No entanto, associa-se a velocidade também à quantidade de informações e estas duas necessidades acabam conflitando.  

Isso porque quanto maior a quantidade de informações requeridas, a velocidade de processamento ou disponibilidade destas informações diminuem consideravelmente. 

Diante deste cenário, como poderíamos conciliar tais distintas e acopladas demandas? 

O que é caching? 

Caching é uma técnica de armazenamento intermediário de dados da aplicação, feitos através de hardware ou software. Ela serve para prover um acesso mais rápido a determinadas informações do que acessar diretamente a base de dados da aplicação. 

Enquanto uma base de dados é focada em gerir as informações, o cache tem como direcionamento a leitura destes dados, não se preocupando com demais operações, pois esta tarefa já está sendo atribuída. 

Com isso temos um acesso mais rápido e direto, ganhando em tempo e performance do acesso a estes dados. 

Caching é uma importante feature para as aplicações, pois ganha em velocidade e performance na obtenção dos dados. Entretanto existe um grande “depende” nesta solução, pois, necessariamente nem todas as aplicações realmente necessitam do uso de caching. Antes de aplicarmos tal conceito devemos sempre analisar a aplicação e a real necessidade perante o uso de caching. 

Devo utilizar caching na minha aplicação? 

Sempre é importante fazer esse questionamento para evitar trabalho desnecessário. Veja algumas questões importantes a considerar: 

• Eu realmente preciso melhorar a performance da minha aplicação? 
• Os meus usuários estão insatisfeitos com a performance? 
• Seria possível alcançar a performance que desejo de outra maneira? Por exemplo, otimizando consultas, criando índices no banco e alterando estrutura dos dados. 

Estas e outras questões podem nos ajudar a validar se realmente temos a necessidade de utilizar caching em nossa aplicação. 

Onde posso utilizar caching? 

1 - Sistemas com foco na leitura de dados 

Consiste em sistemas que a quantidade de leitura dos dados é significativamente  

maior do que a quantidade de escrita. Desse modo, o uso de caching pode ser uma solução para escalar tal aplicação. 

2 - Tolerância do estado do dado 

Sistemas que contém dados que não precisam apresentar a sua versão atual e que possam ser atualizados na base e na aplicação, além de não precisarem de atualização por determinado tempo. Nestes casos, o cache pode ser uma solução para armazenar um valor determinado. 

3 - Dados que não se alteram frequentemente 

Para sistemas que os dados não se atualizam com frequência, o caching pode ser utilizado armazenar por um determinado tempo e consultar sempre de acordo com a necessidade da aplicação. 

Eventos de caching 

Podemos classificar o cache tendo dois tipos de eventos: Hit e Miss. 

Hit 

O dado buscado se encontra no cache quando a aplicação efetua a consulta, obtendo uma resposta mais rápida e leve. 

Miss 

O dado buscado pela aplicação não se encontra no cache, fazendo com que a aplicação tenha que buscá-lo diretamente na base de dados efetuando uma chamada adicional. 

Principais estratégias de caching 

Existem algumas estratégias de caching que podem ser utilizadas para efetuar o processo de caching. As mais comuns são: 

Cache-aside Pattern 

Esta estratégia de leitura consiste na aplicação com acesso a ambas as bases: cache e database. Ela se baseia na aplicação buscando o dado no cache e retornando para a aplicação. Porém se este dado não for encontrado no cache, a aplicação vai buscar diretamente da base dados e retornar para a aplicação, e posteriormente inserir na base de cache. 

Read through / Lazy Loading 

Esta estratégia de leitura consiste na aplicação que não tem acesso a base de dados, apenas a base de cache. Ela solicita o dado ao cache e, caso encontre, prossegue retornando-o para a aplicação. Caso não consiga encontrar a informação, o próprio cache vai até a base, encontra o dado solicitado e o insere na base de cache, e só então retorna-o para a aplicação. 

Read-Through é uma estratégia muito semelhante a Cache-aside, mas a diferença é que nesta estratégia a aplicação sempre irá buscar da base de cache. 

Write through 

Esta estratégia de escrita consiste no cache que consegue armazenar todos os dados da base, que sempre devem ser atuais. 

Toda vez que a aplicação escreve algum dado, primeiramente ele armazena no cache e depois armazena no banco de dados. Dessa forma, o cache sempre tem a versão mais recente da informação sendo uma réplica da base de dados. Esta aplicação sempre lê apenas da base de cache. 

Write through é voltada para sistemas onde a leitura não pode ser em hipótese alguma obsoleta. Entretanto, podem existir dados armazenados e não lidos já que ele acaba armazenando tudo. 

Write-back (Write-behind) 

Nesta estratégia de escrita, o dado não é escrito na base imediatamente, pois a aplicação segue escrevendo no cache e depois de um certo tempo sincroniza na base dados, atuando em lotes de informações a serem inseridas. 

Um dos problemas desta estratégia é que se o cache tiver algum problema, os dados que ainda não foram sincronizados serão perdidos. Além disso, se houver algum tipo de operação direta no banco de dados esta operação pode não utilizar a versão atualizada dos dados. 

Caching implemetation 

Para aplicarmos as estratégias de cache apresentadas anteriormente, devemos escolher uma implementação de caching. Existem várias alternativas e desde que o local de armazenamento do cache seja mais rápido do que o acesso ao banco, já é de grande valor. 

Quando estamos falando de cache, geralmente o seu armazenamento é feito através de “chave/valor”. 

Abaixo apresentaremos 3 tipos comuns de implementação de caching. 

In-Memory 

In Memory caching consiste no armazenamento de dados de caching na própria memória do serviço. Este formato é o mais rápido, pois trabalha com um acesso direto, assim como uma simples variável da aplicação. 

Apesar de ser o mais rápido e fácil de implementar, também traz alguns problemas. Por exemplo, por armazenar na memória do serviço se o mesmo acabar caindo, os dados de cache serão perdidos também. 

Esta implementação é recomendada quando lidamos com serviços únicos ou menores, e que tenham poucos dados a serem armazenados no cache. 

Remote 

Nesta implementação os dados de caching são armazenados em um serviço externo, como o Redis ou Memcached, e não vinculado ao serviço de aplicação. 

Neste formato, o dado se torna resiliente a queda do serviço de aplicação, pois é desacoplado do mesmo e tem seu próprio serviço. 

Este modelo de implementação se faz robusto e recomendado para quando se tem dados oriundos de vários serviços distintos ou em grande. 

Remote Distributed 

Ambos os modelos de implementações citados acima sofrem quando o assunto é escalabilidade. A quantia de dados que podem ser armazenados em cada implementação é limitada, e isso acontece porque ambos dependem apenas de um único servidor, seja ele local ou externo. 

Porém, quando necessitamos gerenciar maiores quantidades de dados, podemos usar o modelo de implementação externo e distribuído, onde distribui-se o cache entre múltiplas instâncias do servidor de cache. 

Se a quantidade atual for insuficiente, então é possível adicionar novos cluster e com isso ter meios de escalar a quantidade de dados possíveis a serem armazenados, facilitando a escalabilidade deste serviço de caching. 

Conclusão 

Caching é um conceito fácil de compreender, sua implementação também é simples e os resultados aparecem já com pequenas aplicações, independente da estratégia e do modelo utilizado. 

Mas nem sempre será o salvador de uma aplicação e necessariamente não são todas que devem utilizar desta estratégia. Porém, se este for o caso, é de grande ajuda utilizá-la. 

Referências 

https://kislayverma.com/software-architecture/architecture-patterns-caching-part-1/

https://blog.devgenius.io/caching-strategy-101-3bc974d2a6cd

https://levelup.gitconnected.com/avoid-using-cache-in-your-application-or-do-it-right-9650214797bc

https://dev-abhishek-gautam.medium.com/the-definitive-guide-to-caching-f7441f6932b7