Cache em aplicações: tempo de expiração, invalidação e proteção contra o efeito manada

O que é

No padrão «cache-aside», a aplicação consulta primeiro o cache; em caso de falha (cache miss), lê a fonte, guarda o resultado com um tempo de expiração e o devolve. O Redis documenta os blocos de construção: EXPIRE define um prazo, e a chave é removida automaticamente quando ele termina, e SET com a opção NX só grava se a chave ainda não existir, o que serve de base para um bloqueio simples. No nível HTTP, a RFC 9111 regula o mesmo princípio de frescor limitado com max-age; caches de aplicação não seguem nenhuma norma, e as regras cabem a quem os projeta.

Por que importa

Um cache reduz carga e latência, mas uma entrada desatualizada após uma escrita é um erro de correção difícil de reproduzir: ele só aparece na janela entre a escrita e a expiração e desaparece quando se tenta reproduzi-lo. Por isso, a estratégia de invalidação faz parte do projeto e não é um ajuste posterior.

Como aplicar

• Definir, para cada classe de dados, a idade máxima aceitável de um valor e ajustar a expiração de acordo; um prazo curto limita o dano de qualquer invalidação esquecida.
• Ao escrever, remover as chaves afetadas em vez de sobrescrevê-las: a remoção é idempotente e não pode deixar um valor mais antigo para trás quando dois escritores se ultrapassam. Mesmo assim, um leitor que é ultrapassado por uma escrita entre a leitura no banco de dados e a gravação no cache pode guardar um valor desatualizado; essa janela só é limitada pelo tempo de expiração.
• Incluir na chave um identificador de versão ou de esquema (kunde:v3:123), para que um deployment com nova estrutura de valores não leia entradas antigas; as antigas expiram por conta própria.
• Considerar as chaves derivadas: quando um objeto muda, também são afetadas as listas, contadores e resultados de busca que o contêm. Ou se removem também essas chaves, ou se atribui a elas um prazo mais curto.
• Evitar o efeito manada («stampede»): quando uma chave muito acessada expira, apenas uma requisição deve consultar a fonte. Com SET sperre:<schlüssel> 1 NX EX 5, um processo obtém o direito de recarregar; os demais esperam um pouco ou devolvem o valor antigo ainda existente. A documentação do Redis chama SET … NX EX de bloqueio simples e remete ao Redlock para bloqueios tolerantes a falhas; para a proteção contra o efeito manada, em que uma falha significa apenas um segundo recarregador, a forma simples basta.
• Guardar em cache resultados negativos («não encontrado») com prazo curto quando muitas requisições visam chaves inexistentes.
• Medir a taxa de acertos e a carga sobre a fonte; um cache sem acertos só acrescenta latência a cada falha.

Armadilhas

Dados dependentes do usuário sob uma chave compartilhada. Tratar o cache como armazenamento durável, embora uma reinicialização o esvazie. Tempos de expiração definidos e verificados em hosts com relógios divergentes. Um bloqueio sem tempo de expiração, que nunca mais é liberado depois que o processo que recarregava falha.