Estratégias de Cache em um App Construído com IA: O Que Cachear e O Que Nunca Cachear

Resposta rápida

Cacheie qualquer coisa que seja cara de computar e lenta para ficar desatualizada — páginas institucionais renderizadas, respostas de APIs de terceiros, resumos gerados por IA sobre dados que não mudaram. Nunca cacheie algo ligado ao estado ao vivo de um usuário específico, como o total de um carrinho ou o saldo de uma conta, sem um caminho de invalidação em que você confie. A maioria dos apps precisa de três camadas, não uma só: o CDN na frente das páginas estáticas, uma camada em memória ou Redis para dados compartilhados, e cache de resposta de curta duração para qualquer coisa que chame um LLM.

O bug que parece uma funcionalidade

Um time lança um app construído com IA, ele é rápido nos testes, e duas semanas depois do lançamento alguém abre um chamado de suporte dizendo "meu painel mostra os números de ontem". Ninguém mexeu no código do painel. O que aconteceu foi que outra pessoa, tentando deixar o app mais rápido sob carga, envolveu uma consulta ao banco de dados num cache de cinco minutos e considerou o assunto resolvido.

Isso não é um bug de cache. É uma estratégia de invalidação ausente, disfarçada de bug de cache.

Cache é fácil de adicionar e fácil de errar de um jeito que não aparece até o tráfego real chegar. O erro não é cachear pouco — a maioria dos apps cacheia de menos e paga o preço em carga no banco de dados. O erro é cachear sem decidir, com antecedência, exatamente quando aquele valor cacheado deixa de ser verdadeiro.

Três perguntas antes de cachear qualquer coisa

Faça estas perguntas antes de recorrer ao Redis: com que frequência esse dado realmente muda, quão ruim é se um usuário ver uma versão levemente desatualizada, e existe um evento específico que deveria limpar o cache? Se você não conseguir responder a terceira, ainda não tem uma estratégia de cache — tem um timer, e timers são como bugs do tipo "números de ontem" nascem.

As três camadas que cobrem quase tudo

Cache de CDN / edge cuida de qualquer coisa que pareça igual para todo visitante — páginas institucionais, posts de blog, documentação. O Next.js faz isso bem com geração estática e Incremental Static Regeneration, onde uma página é construída uma vez, servida a partir do edge, e reconstruída silenciosamente em segundo plano num intervalo que você define:

export const revalidate = 3600; // reconstrói esta página no máximo uma vez por hora

Essa linha única significa que uma página como uma página de preços ou um post de blog é servida instantaneamente a partir de um nó de edge do CDN, e o Next.js cuida de reconstruí-la em segundo plano sem que nenhum usuário jamais espere pela reconstrução.

Cache em memória / Redis é para dados compartilhados entre usuários mas caros demais para recalcular a cada requisição — uma consulta agregada de estatísticas, uma lista de promoções ativas, uma resposta de API de terceiros que você não pode martelar a cada carregamento de página. Redis com um TTL é a ferramenta padrão aqui, e o TTL deveria mapear para a frequência real de mudança do dado subjacente, não um número redondo que pareceu seguro.

Cache de resposta para chamadas de IA é a camada que a maioria dos times pula e depois se arrepende. Se dez usuários fazem a mesma pergunta a um LLM, ou seu app resume o mesmo documento duas vezes dentro de uma hora, você está pagando o custo cheio de LLM por uma resposta que já tinha em mãos. Fazer o hash da entrada e cachear a saída por uma janela curta — mesmo que sejam cinco minutos — corta custo real em qualquer funcionalidade com entradas repetíveis.

Onde a invalidação costuma dar errado

A falha é quase sempre a mesma: uma escrita acontece em algum lugar do app, e nada avisa o cache sobre isso. Um usuário atualiza o perfil, a versão cacheada da página de perfil continua servindo o nome antigo pelos próximos quinze minutos, e agora existe um chamado de suporte. O conserto não é um TTL mais curto — um TTL mais curto só faz o bug acontecer com menos frequência, não faz ele desaparecer. O conserto é invalidar na escrita: quando o handler de atualização roda, ele limpa ou atualiza a chave de cache específica que aquela atualização afeta, a mesma requisição que mudou o dado é responsável por avisar o cache de que ele mudou.

Chaves de cache que incluem exatamente o que torna um valor único — ID do usuário, ID do recurso, um número de versão — tornam isso viável. Uma chave de cache como stats:workspace:{id} é fácil de invalidar na escrita. Uma única chave compartilhada para "todas as estatísticas de workspace" não é, porque você não consegue limpar a entrada de um workspace sem adivinhar se é seguro limpar a de todo mundo junto.

O que nunca deveria entrar num cache compartilhado

Saldos de conta, verificações de permissão, qualquer coisa que controle acesso a conteúdo pago, e personalização por requisição não deveriam ficar atrás de um cache que poderia servir o dado de um usuário para outro, ou servir um "sim, você tem acesso" desatualizado depois que o acesso foi revogado. Se o custo de errar é um problema de segurança ou de cobrança, pule o cache ou restrinja o escopo tão rigidamente a um usuário e uma sessão que um erro não consiga vazar entre contas.

Uma comparação: camadas de cache e para que servem

Onde isso vive em um app construído com a Greta

Um app gerado pela Greta em Next.js ganha ISR de graça em qualquer página que pode ser gerada estaticamente — essa é a primeira vitória de cache que a maioria dos projetos nunca precisa nem pensar. Para a camada Redis, ela fica junto da mesma infraestrutura coberta em rate limiting e prevenção de abuso, já que um rate limiter e um cache convivem bem na mesma instância Redis, só com prefixos de chave e TTLs diferentes.

O padrão de invalidar-na-escrita também combina bem com rodando jobs em segundo plano e tarefas agendadas — se uma escrita dispara um recálculo caro em vez de uma simples limpeza de cache, esse recálculo pertence a um job em fila, não a algo rodando na hora dentro da própria requisição que o disparou. Mantenha a limpeza do cache rápida e síncrona; jogue a reconstrução cara para o segundo plano.

Perguntas frequentes

Devo cachear consultas ao banco de dados por padrão? Não — cacheie as que você já viu aparecerem lentas ou repetidas nos seus logs. Cachear tudo de antemão só adiciona superfície de invalidação para consultas que nunca foram o gargalo.

Um TTL de cinco minutos é um padrão seguro? É um padrão que parece seguro, o que não é a mesma coisa. Escolha o TTL com base na frequência real de mudança do dado subjacente e em quão ruim é uma leitura desatualizada, depois adicione invalidação na escrita para qualquer coisa em que a desatualização realmente confundiria um usuário.

Preciso de Redis para um app pequeno? Nem sempre. Cache em memória dentro de um único processo de servidor funciona bem até você ter mais de uma instância de servidor rodando, momento em que cada instância tem seu próprio cache e os usuários recebem resultados inconsistentes dependendo de qual instância responde à requisição. O Redis resolve isso dando a mesma cache compartilhada para todas as instâncias.

Posso cachear conteúdo gerado por IA por muito tempo? Sim, se a entrada que o produziu não mudou e você não está preocupado com o modelo produzir uma resposta melhor da próxima vez que você perguntar. Trate como qualquer outra computação cacheada — chaveie pela entrada, invalide quando a entrada mudar.

Encerramento

Cache não é uma decisão só, são três ou quatro pequenas decisões empilhadas umas sobre as outras, e a camada que causa dano de verdade quase nunca é o CDN — é o cache compartilhado que ninguém conectou a um caminho de invalidação. Adicione cache onde o dado é genuinamente caro e muda devagar, pule onde errar custa dinheiro ou acesso de alguém, e sempre saiba o evento único que deveria limpar cada chave antes de colocar no ar.

Comece a construir seu app com a Greta hoje.