Redis e cache: como invalidar dados sem mostrar informações antigas
Publicado em 2026-10-26 por frfrand
TTL, chaves e padrões de invalidação ao armazenar APIs em cache
Você adicionou o Redis e sua API agora responde em milissegundos. Perfeito, até que um usuário altera sua reserva e continua vendo o horário anterior. Acelerar dados é fácil; mantê-los atualizados é o que requer design.
A ideia é resolver um problema de dados ou implantação que aparece em aplicações reais. Vamos ver o conceito sem rodeios, um exemplo de implementação e o que verificar antes de levá-lo para produção.
O que faz Invalidar cache no Redis
O Redis pode armazenar chaves com TTL e atender leituras repetidas. A invalidação consiste em decidir quando expira ou se exclui cada dado ao alterar a fonte principal. O padrão depende se você aceita dados temporariamente antigos e de quantos processos podem gravar.
Não basta repetir uma receita se você não entender quem lê os dados, de qual processo e com quais permissões. Em um aplicativo com reservas, faturas ou usuários, uma condição de corrida ou uma política de acesso mal feita pode ser mais grave do que uma API lenta.
Um exemplo concreto
# Ejemplo desde redis-cli en entorno de prueba
SET horarios:42 '{"plazas":3}' EX 60
GET horarios:42
TTL horarios:42
DEL horarios:42
# Usar prefijos claros y evitar borrar claves de otras appsOs nomes, tabelas e chaves deste exemplo são ilustrativos. Teste primeiro em um banco ou ambiente de homologação e adapte permissões, índices e versões. Quando houver operações de gravação, não execute consultas de amostra sobre dados de clientes sem revisar o que elas modificam.
Passo a passo
- Escolha apenas leituras repetidas que realmente justifiquem cache.
- Defina a estrutura de chaves por entidade e, se houver vários clientes, por tenant.
- Atribua TTL de acordo com o risco de exibir informações desatualizadas.
- Ao modificar o PostgreSQL, invalide as chaves afetadas após confirmar a transação.
- Meça a taxa de acerto e verifique a consistência com testes de alterações concorrentes.
No final, não fique com «o SQL não deu erro». Comprove o efeito real pela API e com testes de concorrência ou permissões, conforme o caso. Em bancos de dados, há erros que só aparecem quando dois usuários fazem algo ao mesmo tempo.
Exemplo de projeto de trabalho
A página pública de passeios mostra horários e vagas. Você pode armazenar em cache a lista por alguns segundos, mas ao confirmar uma reserva sempre deve verificar a disponibilidade no PostgreSQL sob controle transacional.
Esse cenário ajuda a distinguir desempenho de consistência. Acelerar uma consulta não serve se permitir criar duas reservas para uma única vaga, nem um banco enorme resolve o fato de o backend permitir consultar dados de outro cliente.
O erro típico
Não use cache como fonte definitiva para pagamentos ou vagas sem mecanismos de consistência. FLUSHALL em um Redis compartido pode afetar outros projetos; gerencie namespaces e bancos com cuidado.
Também vale a pena ter um plano de recuperação. Antes de mexer no esquema, usuários ou políticas, faça uma cópia verificável ou migração reversível e verifique se o aplicativo pode continuar funcionando durante a mudança.
Como resolveria com ArduMaker?
O ArduMaker pode hospedar Redis junto ao PostgreSQL e uma API em um VPS. Defina limites de memória e proteção de acesso; Redis sem autenticação ou rede restrita não é uma boa ideia.
O ArduMaker permite implantar serviços a partir do Git e trabalhar com bancos de dados e processos dentro do VPS. O painel não substitui a lógica do seu aplicativo: transações, permissões e validações devem estar corretamente projetadas no código e no banco de dados.
Três verificações antes de publicar
Integridade: se uma solicitação for repetida ou falhar no meio do caminho, os dados terminam em um estado válido?
Segurança: um usuário autenticado pode acessar apenas suas informações, e a API utiliza uma identidade de banco de dados com permissões mínimas?
Recuperação: você sabe restaurar os dados e reverter a versão de código compatível se uma atualização der errado?
Se você puder responder a essas três perguntas com provas, seu backend está bastante mais preparado do que quando você apenas verificou se o endpoint retornava 200.
Recursos para aprofundar
Para encerrar: escolha a solução mais simples que permita manter dados corretos, seguros e recuperáveis. O desempenho vem depois de medir.