Estrategias de almacenamiento en caché: almacenamiento en caché de Redis, CDN y HTTP para aplicaciones web

El almacenamiento en caché es la técnica más eficaz para mejorar el rendimiento de las aplicaciones. Una caché bien diseñada puede reducir la carga de la base de datos en un 90 %, recortar los tiempos de respuesta de 200 ms a 2 ms y ahorrar miles de dólares en costos de infraestructura mensualmente. Sin embargo, el almacenamiento en caché es también una de las áreas más incomprendidas de la ingeniería de software: los errores de invalidación crean datos obsoletos, las estampidas de caché hacen caer los servidores y los TTL mal elegidos desperdician memoria o ofrecen contenido obsoleto.

Conclusiones clave

• Diseñar el almacenamiento en caché en capas: del navegador a la CDN, a la aplicación (Redis) y al caché de consultas de la base de datos: cada capa maneja diferentes características de datos
• El patrón de caché aparte de Redis es el valor predeterminado más seguro: leer desde el caché, recurrir a la base de datos, completar el caché en caso de error.
• Los encabezados de caché HTTP (Cache-Control, ETag, Vary) eliminan por completo las solicitudes innecesarias: la solicitud más rápida es aquella que nunca llega a su servidor.
• La invalidación de la caché es más difícil que el almacenamiento en caché: utilice la caducidad basada en TTL como estrategia principal y la invalidación basada en eventos para mantener los datos críticos actualizados.

---

La jerarquía de caché

El almacenamiento en caché eficaz funciona en capas, y cada capa está optimizada para diferentes requisitos de latencia, capacidad y frescura.

Capa 1: caché del navegador

La caché del navegador es la más rápida y económica porque elimina por completo la solicitud de red. Los encabezados HTTP Cache-Control controlan el comportamiento del almacenamiento en caché del navegador.

Para activos estáticos con nombres de archivos con contenido hash (como la salida de compilación de Next.js), configure Cache-Control: public, max-age=31536000, immutable. El hash de contenido en el nombre del archivo garantiza que el contenido modificado obtenga una nueva URL, por lo que puede almacenar en caché de forma agresiva sin preocuparse por el contenido obsoleto.

Para páginas HTML y respuestas API, utilice TTL más cortos con revalidación: Cache-Control: public, max-age=60, stale-while-revalidate=300. Esto entrega contenido almacenado en caché durante 60 segundos, luego se revalida en segundo plano mientras continúa entregando contenido obsoleto por hasta 5 minutos.

Capa 2: caché perimetral de CDN

Una CDN almacena en caché el contenido en servidores periféricos distribuidos globalmente, lo que reduce la latencia al servir el contenido desde la ubicación más cercana a cada usuario. Para una base de usuarios global, el almacenamiento en caché de CDN reduce la latencia promedio de 200 a 500 ms (ida y vuelta del servidor de origen) a 10 a 50 ms (borde más cercano).

Qué almacenar en caché en CDN:

• Todos los activos estáticos (JavaScript, CSS, imágenes, fuentes)
• Páginas de marketing públicas (con TTL corto para la actualidad del contenido)
• Páginas del catálogo de productos (TTL de 5 a 15 minutos para comercio electrónico)
• Respuestas API para datos públicos (listados de productos, contenido de blog)

Qué NO almacenar en caché en CDN:

• Respuestas API autenticadas (datos específicos del usuario)
• Carrito de compras y páginas de pago.
• Páginas del panel de administración
• Puntos finales de webhook
• Cualquier respuesta con encabezados Set-Cookie

Capa 3: Caché de aplicaciones (Redis)

Redis proporciona acceso con latencia de microsegundos a los datos almacenados en caché, lo que lo hace ideal para datos costosos de calcular o a los que se accede con frecuencia. A diferencia del almacenamiento en caché de CDN, Redis puede almacenar en caché datos autenticados y específicos del usuario porque su aplicación controla el acceso.

Capa 4: Caché de consultas de base de datos

PostgreSQL mantiene un caché de búfer (shared_buffers) que almacena en caché las tablas a las que se accede con frecuencia y las páginas de índice en la memoria. Si bien no se puede controlar directamente por consulta, la configuración adecuada garantiza que los datos activos permanezcan en la memoria. Para consultas de informes, considere las vistas materializadas que calculan previamente agregaciones costosas.

---

Patrones de almacenamiento en caché de Redis

Redis es el caché a nivel de aplicación más popular para aplicaciones web y admite cadenas, hashes, listas, conjuntos, conjuntos ordenados y transmisiones. El patrón que elija determina cómo se comporta su caché en casos extremos.

Caché aparte (carga diferida)

La caché aparte es el patrón predeterminado más seguro. La aplicación verifica primero Redis. En un acierto de caché, devuelve los datos almacenados en caché. En caso de error de caché, consulta la base de datos, almacena el resultado en Redis con un TTL y devuelve los datos.

Ventajas:

• Sólo se almacenan en caché los datos solicitados (no se desperdicia memoria con datos no utilizados)
• El fallo de la base de datos sólo afecta a los errores de caché, no a los aciertos de caché.
• Sencillo de implementar y razonar.

Desventajas:

• La primera solicitud de cada clave siempre llega a la base de datos (arranque en frío)
• Es posible que haya datos obsoletos entre la actualización de la base de datos y la caducidad de la caché.

Escritura simultánea

En el almacenamiento en caché de escritura directa, cada escritura en la base de datos también actualiza el caché inmediatamente. La aplicación escribe tanto en la base de datos como en Redis en la misma operación.

Ventajas:

• La caché siempre está actualizada: no hay ventana de datos obsoletos
• El rendimiento de lectura es siempre rápido (no se pierde caché después de la escritura inicial)

Desventajas:

• Aumenta la latencia de escritura (dos escrituras por operación)
• La caché puede contener datos que nunca se leen (memoria desperdiciada)
• Requiere un manejo cuidadoso de errores cuando una escritura tiene éxito y la otra falla

Escritura retrasada (escritura posterior)

El almacenamiento en caché de escritura retrasada escribe en Redis inmediatamente pero difiere la escritura de la base de datos a un proceso en segundo plano. Esto reduce la latencia de escritura, pero introduce el riesgo de pérdida de datos si Redis falla antes de que se complete la escritura en la base de datos.

Úselo con moderación: este patrón es apropiado para contadores de análisis, limitación de tasas y datos de sesiones donde la pérdida ocasional de datos es aceptable, no para transacciones financieras o recuentos de inventario.

Prevención de estampida de caché

Una estampida de caché ocurre cuando una clave de caché popular expira y cientos de solicitudes simultáneas consultan la base de datos simultáneamente para reconstruirla. Esto puede sobrecargar la base de datos.

Estrategias de prevención:

1. Obsoleto mientras se revalida: proporciona datos ligeramente obsoletos mientras una solicitud reconstruye el caché en segundo plano.
2. Bloqueo Mutex: use Redis SETNX para garantizar que solo una solicitud reconstruya el caché mientras otras esperan o entregan datos obsoletos.
3. Vencimiento anticipado probabilístico: vuelva a calcular aleatoriamente antes del vencimiento del TTL, distribuyendo las reconstrucciones a lo largo del tiempo en lugar de concentrarlas al vencimiento.

---

Diseño de estrategia TTL

Los valores de tiempo de vida (TTL) determinan cuánto tiempo permanecen los datos en la memoria caché. Si es demasiado corto, se producirán errores excesivos de caché. Demasiado tiempo y entregará datos obsoletos.

TTL deslizante versus TTL fijo

El TTL fijo caduca la clave en un momento determinado después de la creación. El TTL deslizante restablece el vencimiento cada vez que se accede a la clave. Utilice TTL deslizante para los datos de la sesión (mantenga vivas las sesiones activas) y TTL fijo para las cachés de contenido (garantice la actualización periódica desde la fuente).

---

Análisis profundo de encabezados de caché HTTP

HTTP caching is powerful because it works at every layer -- browser, CDN, proxies, and load balancers all understand the same headers.

Directivas de control de caché

• público: cualquier caché (navegador, CDN, proxy) puede almacenar la respuesta.
• privado: solo el navegador puede almacenar en caché (no CDN ni servidores proxy): se usa para respuestas autenticadas
• no-cache: almacena en caché la respuesta, pero vuelve a validarla con el servidor antes de usarla (nombre engañoso: almacena en caché)
• no-store - no almacenar en caché en absoluto (datos confidenciales como páginas bancarias)
• max-age=N -- el caché es válido durante N segundos
• s-maxage=N -- Duración de la caché CDN/proxy (anula la edad máxima para las cachés compartidas)
• stale-when-revalidate=N: ofrece contenido obsoleto durante N segundos mientras se revalida en segundo plano.
• inmutable: el contenido nunca cambiará (úselo con URL con contenido hash)

ETag y solicitudes condicionales

Las ETags proporcionan validación de caché basada en contenido. El servidor genera un hash del contenido de la respuesta y lo envía como encabezado de ETag. En solicitudes posteriores, el navegador envía la ETag en un encabezado If-None-Match. If the content has not changed, the server responds with 304 Not Modified (no body), saving bandwidth.

Utilice ETags para respuestas de API donde el contenido cambia de manera impredecible y el almacenamiento en caché basado en TTL sería demasiado agresivo o demasiado conservador.

Variar encabezado

El encabezado Vary le dice a los cachés que la respuesta depende de encabezados de solicitud específicos. Por ejemplo, Vary: Accept-Encoding significa que las versiones de gzip y Brotli se almacenan en caché por separado. Vary: Accept-Language almacena en caché las versiones de diferentes idiomas por separado.

Tenga cuidado con Vary: cada combinación única de encabezados variados crea una entrada de caché separada. Vary: Cookie deshabilita efectivamente el almacenamiento en caché porque cada usuario tiene cookies diferentes.

---

Estrategias de invalidación de caché

La invalidación de la caché es uno de los dos problemas difíciles de la informática. El objetivo es eliminar o actualizar los datos almacenados en caché cuando cambian los datos de origen, sin introducir lecturas obsoletas ni errores de caché innecesarios.

Vencimiento basado en TTL

La estrategia de invalidación más sencilla y fiable. Establezca un TTL en cada clave almacenada en caché y acepte que los datos pueden estar ligeramente obsoletos dentro de la ventana TTL. Para la mayoría de los casos de uso, un TTL de 5 minutos proporciona un excelente equilibrio entre frescura y rendimiento.

Invalidación impulsada por eventos

Cuando cambia un registro de base de datos, publica un evento que activa la eliminación de la caché. Esto proporciona frescura casi instantánea pero agrega complejidad y modos de falla. Si el evento se pierde (problema de red, falla de la cola), la caché sirve datos obsoletos hasta que expire el TTL.

Utilice la invalidación basada en eventos para datos críticos, como recuentos de inventario y precios, y confíe en TTL para todo lo demás.

Invalidación basada en etiquetas

Algunos sistemas de almacenamiento en caché admiten el etiquetado de entradas de caché con etiquetas. Cuando invalida una etiqueta, todas las entradas con esa etiqueta se eliminan. Esto es útil para invalidar todos los datos almacenados en caché relacionados con una entidad específica (por ejemplo, todos los cachés relacionados con productos cuando se actualiza un catálogo de productos).

---

Preguntas frecuentes

¿Cómo decido qué almacenar en caché?

Datos en caché que se leen con frecuencia, costosos de calcular y tolerantes a estancamientos breves. Las páginas del catálogo de productos, los permisos de usuario, las métricas del panel calculadas y los datos de configuración son excelentes candidatos. Los carritos de compras, los recuentos de inventario en tiempo real y las transacciones financieras generalmente no deben almacenarse en caché o deben utilizar TTL muy cortos con invalidación basada en eventos.

¿Qué sucede cuando Redis deja de funcionar?

Con el patrón de caché aparte, su aplicación vuelve a consultar la base de datos directamente. Los tiempos de respuesta aumentan pero la aplicación sigue siendo funcional. Diseñe su aplicación para manejar los errores de caché con elegancia: Redis debe ser una optimización del rendimiento, no un único punto de falla.

¿Cuánta memoria debo asignar a Redis?

Supervise la tasa de aciertos de caché y el uso de memoria. Una tasa de aciertos superior al 95 % con una utilización de la memoria inferior al 80 % indica un buen tamaño. Si la tasa de aciertos cae por debajo del 90%, necesita más memoria o sus TTL son demasiado cortos. Comience con 1-2 GB para la mayoría de las aplicaciones y escale según los datos de monitoreo.

¿Debería usar Redis o Memcached?

Redis es la mejor opción predeterminada para la mayoría de las aplicaciones. Admite más tipos de datos, opciones de persistencia, publicación/suscripción para invalidación basada en eventos y secuencias de comandos Lua para operaciones atómicas. Memcached es más simple y ligeramente más rápido para el almacenamiento en caché de valores clave puros a escala extrema, pero Redis cubre más casos de uso.

¿Cómo evito entregar datos obsoletos después de una implementación?

Incluya un identificador de versión en sus claves de caché (por ejemplo, claves de prefijo con la versión de implementación o una versión de esquema). Cuando se implementa, la nueva versión utiliza nuevas claves de caché y las claves antiguas caducan naturalmente a través de TTL. Alternativamente, vacíe todo el caché durante la implementación si su aplicación maneja los cachés fríos correctamente.

---

¿Qué sigue?

Comience implementando encabezados de caché HTTP para sus activos estáticos y páginas públicas; esto proporciona una mejora inmediata del rendimiento sin cambios en la aplicación. Luego agregue el almacenamiento en caché de Redis para sus consultas de bases de datos y puntos finales de API más costosos.

Para obtener una imagen completa de la optimización del rendimiento, consulte nuestra guía fundamental sobre ampliar su plataforma empresarial. Para optimizar la fuente de datos que alimenta su caché, lea nuestra guía sobre optimización de consultas de bases de datos.

ECOSIRE implementa arquitecturas de almacenamiento en caché para plataformas que se ejecutan en Odoo ERP y Shopify. Comuníquese con nuestro equipo para una revisión de la estrategia de almacenamiento en caché.

---

Publicado por ECOSIRE: ayuda a las empresas a escalar con soluciones impulsadas por IA en Odoo ERP, Shopify eCommerce y OpenClaw AI.