Mejores prácticas de caché

Define la invalidación antes de almacenar en caché rutas críticas. Redis es rápido; un diseño de caché incorrecto es lento de depurar.

Cómo usar esta lista

• Requiere una nota de diseño de caché en las PR que añaden nuevas familias de claves
• Ejecuta pruebas de carga con Redis deshabilitado para verificar la ruta de degradación
• Combínalo con Conceptos básicos de caché para patrones
• Revisa los TTL después de cambios en el esquema o la forma de la API

A - Diseño de claves

• Claves con espacio de nombres: env:service:version:entity:id.
• Propietario de la invalidación nombrado en el comentario del código o ADR por familia de claves.
• TTL en cada clave a menos que sea una configuración eterna explícita con invalidación de flujo de cambios.
• Cardinalidad de clave limitada - no hay cadenas generadas por el usuario ilimitadas en las claves.
• Incremento del prefijo de versión cuando cambia la forma serializada.

B - Consistencia

• Cache-aside con la base de datos como fuente de verdad para la mayoría de las lecturas.
• Elimina o actualiza la caché en la escritura en el mismo caso de uso que la mutación de la base de datos.
• Protección contra estampidas en las claves más populares (bloqueo, fluctuación, actualización temprana).
• TTL corto para el almacenamiento en caché negativo (resultados de fallos) para proteger la base de datos.
• No almacenar en caché saldos financieros fuertemente consistentes sin la aprobación explícita del producto.

C - Operaciones

• Cliente ioredis singleton por proceso con manejador de errores.
• Alertas de memoria en la instancia de Redis (maxmemory, evictions).
• Métricas de aciertos/fallos por endpoint o prefijo de clave en staging antes de producción.
• Base de datos lógica o instancia de Redis separada para BullMQ vs caché orientada al usuario cuando la carga es alta.
• TLS y AUTH habilitados en Redis gestionado en producción.

D - Seguridad

• No hay secretos en los valores de caché a menos que estén cifrados a nivel de aplicación.
• Las cookies de sesión solo contienen IDs - consulta Almacenes de sesión.
• Aislamiento multi-inquilino en cada prefijo de clave.
• Redis no expuesto a internet público - solo VPC/enlace privado.
• Usuarios ACL con el menor privilegio en Redis 6+.

E - Integración de aplicaciones

• Degradación elegante cuando Redis agota el tiempo de espera - registra y vuelve al origen.
• Tamaño de la carga útil JSON revisado - almacena DTOs en caché, no grafos de objetos completos.
• Pipeline multi-get para lecturas por lotes en lugar de N gets secuenciales.
• redis.quit() al apagar junto con el cierre del pool HTTP y DB.
• Bloqueos distribuidos mantenidos < pocos segundos - consulta Bloqueos distribuidos.

F - Cuándo no almacenar en caché

• Omite la caché cuando la tasa de aciertos < 30% después del período de medición.
• Omite los datos mutables por usuario con baja lectura repetida dentro de la ventana TTL.
• Prefiere CDN para activos públicos estáticos antes de Redis.
• Prefiere el índice de la base de datos antes de Redis si la consulta es lenta debido a un índice faltante.
• Encola la recomputación pesada en lugar de grandes blobs almacenados en caché.

Preguntas frecuentes

Relacionado

• Conceptos básicos de caché - ejemplos de cache-aside
• ioredis - patrones de cliente
• Almacenes de sesión - sesiones de cookies
• Conceptos básicos de rendimiento - latencia
• Conceptos básicos de resiliencia - modos de degradación

Versiones de pila: Esta página fue escrita para Node.js 24.18.0 (LTS activa), npm 10+, TypeScript 5.6+, Express 5, Fastify 5 y NestJS 11.