Estratégias de cache: carregamento sob demanda e gravação simultânea

Inserir um cache entre sua aplicação e o banco de dados exige uma estratégia de cache — um conjunto de regras que determina quando os dados são colocados no cache, quando são lidos do cache e quando são removidos. Escolher a estratégia errada resulta em dados desatualizados (o cache retorna valores antigos), falhas por cache frio (o cache está vazio e cada solicitação acessa o banco de dados) ou avalanche de cache (muitas solicitações simultâneas para a mesma chave ausente acessam o banco de dados ao mesmo tempo). As duas estratégias fundamentais são o carregamento lento e a gravação direta no cache.

O carregamento lento (também chamado de cache-aside) é o padrão de cache mais comum. A aplicação verifica primeiro o cache. Em um acerto de cache, os dados são retornados diretamente do cache — o caminho rápido. Em uma falha de cache, a aplicação busca os dados no banco de dados, grava o resultado no cache com um TTL e o retorna ao solicitante. O cache é preenchido somente com os dados que realmente são solicitados — daí o termo “lento”. A próxima solicitação da mesma chave a encontrará no cache.

O carregamento lento tem três vantagens principais: somente os dados solicitados são armazenados em cache — o cache não é preenchido com dados que ninguém lê, portanto a memória é usada com eficiência. Um cache frio não interrompe a aplicação — em caso de falhas de cache, a aplicação recorre ao banco de dados; assim, mesmo que o ElastiCache seja reiniciado ou um nó falhe, a aplicação continua funcionando, embora com maior latência. O cache é sempre eventualmente consistente com o banco de dados, porque os dados desatualizados expiram por meio do TTL, mesmo que algumas atualizações não tenham sido consideradas.

O carregamento lento tem três desvantagens principais: as falhas de cache são dispendiosas — são necessárias três operações (verificação do cache, leitura do banco de dados e gravação no cache), em comparação com uma em caso de acerto, o que causa maior latência nas solicitações de um cache frio. Dados desatualizados — após uma atualização no banco de dados, o cache continua fornecendo o valor antigo até o TTL expirar ou a chave ser explicitamente invalidada (janela de inconsistência do cache). Avalanche de cache — se uma chave popular expirar, muitas solicitações simultâneas terão uma falha de cache e acessarão o banco de dados ao mesmo tempo, podendo sobrecarregá-lo.

Na estratégia de gravação direta no cache, cada gravação no banco de dados também é gravada simultaneamente no cache. A aplicação grava tanto no cache quanto no banco de dados como parte da mesma operação (ou o banco de dados aciona uma atualização do cache). Dessa forma, o cache está sempre sincronizado com o banco de dados — não há uma janela de dados desatualizados. A gravação direta no cache garante que os dados armazenados estejam sempre atualizados, fazendo com que as leituras seguintes de dados gravados recentemente sejam sempre acertos de cache.

Vantagens da gravação direta no cache: os dados do cache estão sempre atualizados — não há dados desatualizados, pois o cache é atualizado a cada gravação. As leituras são sempre rápidas — os dados populares gravados com frequência estão sempre no cache. Não há avalanche de cache nas leituras — como os dados são pré-carregados antes de serem lidos, não há falhas por cache frio para dados gravados recentemente. Essa estratégia é ideal para cargas de trabalho com predominância de leitura e atualizações frequentes, nas quais a atualização dos dados é essencial, como catálogos de produtos, sistemas de preços ou caches de perfis de usuários.

Desvantagens da gravação direta no cache: penalidade de gravação — cada gravação envolve duas operações (banco de dados + cache), aumentando a latência das gravações. Poluição do cache — os dados são armazenados mesmo que nunca sejam lidos novamente (gravados uma vez e nunca solicitados), desperdiçando memória do cache. A reinicialização do cache resulta em um cache frio — se o cluster de cache for reiniciado, todos os dados gravados proativamente serão perdidos, e o cache deverá ser preenchido novamente por meio de gravações ou de um processo de aquecimento do cache. Combine a gravação direta no cache com um TTL para evitar o crescimento ilimitado de dados armazenados que raramente são lidos.

Na prática, muitos sistemas de produção combinam as duas estratégias: use a gravação direta no cache para dados atualizados e lidos com frequência (como sessões de usuários ou preços atuais) e o carregamento lento para dados raramente atualizados e lidos com frequência (como descrições de produtos ou conteúdo de artigos). Defina TTLs apropriados para ambos: as chaves gravadas diretamente no cache recebem um TTL longo, pois os dados estão sempre atualizados; as chaves carregadas lentamente recebem um TTL mais curto para limitar a janela de dados desatualizados. Essa abordagem híbrida maximiza a taxa de acertos do cache e minimiza a desatualização.

O Time-To-Live (TTL) dos dados armazenados em cache controla a janela máxima de dados desatualizados e o uso de memória do cache. Defina os TTLs com base na: frequência de atualização dos dados (os dados de sessão mudam com frequência → TTL curto; o conteúdo estático muda raramente → TTL longo), tolerância à desatualização (preços financeiros → muito curto; texto de uma publicação de blog → horas ou dias) e capacidade de memória do cache (pouca memória → TTL mais curto para remover dados desatualizados mais rapidamente). Sempre defina um TTL — nunca armazene dados sem expiração, pois o cache acabará ficando cheio de dados desatualizados.

Em vez de depender somente da expiração do TTL, você pode invalidar explicitamente (excluir) as chaves do cache quando os dados subjacentes forem alterados. Isso elimina completamente a janela de dados desatualizados. Padrões comuns: exclusão na gravação (excluir a chave do cache após cada atualização do banco de dados — a próxima leitura a preenche novamente por meio do carregamento lento) e invalidação orientada por eventos (o DynamoDB Streams ou a captura de alterações do RDS aciona uma função Lambda que exclui as chaves afetadas). A invalidação do cache é um dos problemas mais difíceis em sistemas distribuídos; quanto mais simples for a lógica de invalidação, mais confiável será o seu cache.

Um padrão menos comum, mas poderoso, é a gravação posterior (write-back): a aplicação grava somente no cache, e o cache descarrega os dados de forma assíncrona para o banco de dados em segundo plano. Isso proporciona gravações extremamente rápidas (somente em memória), ao custo de uma possível perda de dados se o cache falhar antes de descarregá-los. A gravação posterior é apropriada para gravações de alta frequência e grande volume, nas quais os dados podem ser reconstruídos ou pequenas perdas são aceitáveis — como contadores de acertos, eventos de análise ou atualizações de pontuações de jogos. O ElastiCache não oferece suporte nativo à gravação posterior; ela deve ser implementada na camada da aplicação.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: o carregamento lento preenche o cache após falhas de leitura e usa a memória com eficiência, mas pode fornecer dados desatualizados até o TTL expirar; a gravação direta no cache atualiza o cache a cada gravação, eliminando dados desatualizados, mas desperdiça memória com dados não lidos; e a invalidação explícita exclui as chaves do cache após atualizações no banco de dados para eliminar as janelas de dados desatualizados. A seguir, exploraremos o armazenamento de sessões e os padrões de tabelas de classificação com o ElastiCache.