Redis y caché: cómo invalidar datos sin mostrar información vieja
Publicado el 2026-10-26 por frfrand
TTL, claves y patrones de invalidación al almacenar en caché APIs
Agregaste Redis y tu API ahora responde en milisegundos. Perfecto, hasta que un usuario cambia su reserva y sigue viendo el horario anterior. Acelerar datos es fácil; mantenerlos actualizados es lo que requiere diseño.
La idea es resolver un problema de datos o despliegue que aparece en aplicaciones reales. Vamos a ver el concepto sin vueltas, un ejemplo de implementación y qué comprobar antes de llevarlo a producción.
Qué hace Invalidar caché en Redis
Redis puede guardar claves con TTL y servir lecturas repetidas. La invalidación consiste en decidir cuándo expira o se borra cada dato al cambiar la fuente principal. El patrón depende de si aceptás datos temporalmente viejos y de cuántos procesos pueden escribir.
No alcanza con repetir una receta si no entendés quién lee los datos, desde qué proceso y con qué permisos. En una aplicación con reservas, facturas o usuarios, una condición de carrera o una política de acceso mal hecha puede ser más grave que una API lenta.
Un ejemplo 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 appsLos nombres, tablas y claves de este ejemplo son ilustrativos. Probalo primero en una base o entorno de ensayo y adaptá permisos, índices y versiones. Cuando haya operaciones de escritura, no ejecutes consultas de muestra sobre datos de clientes sin revisar qué modifican.
Paso a paso
- Elegí sólo lecturas repetidas que realmente justifiquen caché.
- Definí estructura de claves por entidad y, si hay varios clientes, por tenant.
- Asigná TTL acorde al riesgo de mostrar información desactualizada.
- Al modificar PostgreSQL, invalidá claves afectadas tras confirmar la transacción.
- Medí hit rate y verificá consistencia con pruebas de cambios concurrentes.
Al final no te quedes con «el SQL no dio error». Comprobá el efecto real desde la API y con pruebas de concurrencia o permisos según corresponda. En bases de datos hay errores que sólo aparecen cuando dos usuarios hacen algo a la vez.
Ejemplo de proyecto de trabajo
La página pública de tours muestra horarios y plazas. Podés cachear la lista durante algunos segundos, pero al confirmar una reserva siempre debés comprobar disponibilidad en PostgreSQL bajo control transaccional.
Ese escenario ayuda a distinguir rendimiento de consistencia. Acelerar una consulta no sirve si permite crear dos reservas para una sola plaza, ni una base enorme arregla que el backend permita consultar datos de otro cliente.
El error típico
No uses caché como fuente definitiva para pagos o plazas sin mecanismos de consistencia. FLUSHALL en un Redis compartido puede afectar a otros proyectos; gestioná namespaces y bases con cuidado.
También conviene tener un plan de recuperación. Antes de tocar esquema, usuarios o políticas, guarda una copia verificable o migración reversible y comprueba que la aplicación pueda seguir funcionando durante el cambio.
¿Cómo lo resolvería con ArduMaker?
ArduMaker puede alojar Redis junto a PostgreSQL y una API en un VPS. Define límites de memoria y protección de acceso; Redis sin autenticación ni red restringida no es una buena idea.
ArduMaker te permite desplegar servicios desde Git y trabajar con bases y procesos dentro del VPS. El panel no reemplaza la lógica de tu aplicación: transacciones, permisos y validaciones deben quedar correctamente diseñados en el código y la base de datos.
Tres comprobaciones antes de publicar
Integridad: si una petición se repite o falla a mitad de camino, ¿los datos terminan en un estado válido?
Seguridad: ¿un usuario autenticado puede acceder solo a su información, y la API utiliza una identidad de base con permisos mínimos?
Recuperación: ¿sabes restaurar los datos y revertir la versión de código compatible si una actualización sale mal?
Si puedes responder a esas tres preguntas con pruebas, tu backend está bastante mejor preparado que cuando solo miraste si el endpoint devolvía 200.
Recursos para profundizar
Para cerrar: elegí la solución más simple que permita mantener datos correctos, seguros y recuperables. El rendimiento viene después de medir.