Uma chave quente do cache expira e o seu banco de dados cai. O que aconteceu, e como você previne isso?

Isso é um cache stampede, às vezes chamado de thundering herd. Milhares de requisições concorrentes dão miss no mesmo instante e todas recalculam o mesmo valor. Corrija com lock de single flight, para que só um worker recalcule enquanto os outros esperam ou servem dado obsoleto. Acrescente jitter aos TTLs para que as chaves não expirem juntas, atualize chaves quentes em segundo plano antes da expiração, e sirva dado obsoleto em caso de erro.

É um stampede. A chave expira, dez mil requisições em voo dão miss simultaneamente, e todas rodam a mesma query cara, então o banco vê dez mil cópias de uma query que ele normalmente vê uma vez por minuto. A primeira correção é coalescência, então um lock de single flight no cache faz um worker recalcular e todo mundo esperar aquele resultado ou receber o valor obsoleto. A gente usou um lock com SETNX no Redis, com um TTL curto, e a carga no banco naquele caminho caiu umas duas ordens de grandeza. Além disso eu acrescento jitter em todo TTL, então em vez de exatamente 300 segundos é 300 mais ou menos 10%, o que descorrelaciona a expiração entre as chaves. Para chaves genuinamente quentes eu prefiro recálculo antecipado probabilístico, em que uma requisição perto do fim do TTL atualiza em segundo plano enquanto ainda serve o valor em cache. E eu sempre cacheio resultados negativos, senão uma linha ausente vira um loop de query sem limite.