La caché HTTP es sencilla en teoría: cuando los valores de Cache-Control, ETag y TTL son correctos, los clientes e intermediarios reutilizan la misma respuesta. En producción, las aplicaciones envían rutinariamente estos headers faltantes, incorrectos o demasiado restrictivos. El resultado es que el contenido cacheable sigue llegando innecesariamente al backend.
Incluso para activos estáticos, las pequeñas diferencias de URL erosionan la eficiencia del caché. La misma imagen de producto o página de catálogo puede comportarse como un objeto diferente debido a parámetros de seguimiento. El host, la query string, los headers del cliente o un header Cache-Control mal configurado reducen innecesariamente el ratio de aciertos de caché.
Para el contenido dinámico el problema es mayor. El mismo path puede devolver respuestas diferentes para móvil y escritorio; los precios pueden variar por país; el mismo endpoint puede producir datos diferentes por tenant. Si la clave de caché no lleva ese contexto, se devuelve el contenido incorrecto. Añadir demasiados headers a la clave de caché y la caché apenas funciona en absoluto.
Las soluciones de caché externa o CDN son útiles en el borde de internet, pero no siempre son adecuadas para tráfico on-premises, de API privada o de nube soberana. Hacer caché en la capa ADC típicamente requiere archivos de configuración, un lenguaje de reglas personalizado o un producto separado.
TR7 Caché de Respuesta reúne perfiles de caché, reglas condicionales, claves de caché dinámicas y opciones de anulación estándar bajo un único modelo de gestión de vService.
TR7 gestiona el comportamiento de caché a través de cuatro capas: perfiles, condiciones, claves dinámicas y anulaciones controladas.
Un perfil de caché reúne en un lugar el nombre, tamaño, TTL, comportamiento ETag y configuración de headers de depuración. El mismo perfil puede compartirse entre múltiples vServices mientras cada servicio se rige por sus propios límites de caché.
Cada regla de caché se vincula a path, método, header, cookie u otras variables a través del motor de condición FX. Un catálogo público en el mismo backend puede cachearse mientras el carrito del usuario se excluye — sin cambiar ningún código de la aplicación.
El país, tipo de dispositivo, ID de tenant, segmento de usuario o un header personalizado pueden añadirse a la clave de caché. La misma URL se divide en slots de caché separados por contexto, preservando la velocidad de caché mientras se refuerza la corrección del contenido.
Las comprobaciones de host, query string, header de solicitud y header de respuesta pueden anularse deliberadamente. Los backends mal configurados o los parámetros de seguimiento ya no suprimen los ratios de aciertos. Los operadores deciden explícitamente qué estándar anular y cuándo.
La Caché de Respuesta hace que cada comportamiento — desde el perfil de caché hasta la clave dinámica — sea configurable a nivel de vService.
Cada perfil se define con un nombre, tamaño máximo y timeout. El límite de tamaño mantiene el uso de caché por servicio bajo control. El timeout es configurable en segundos, minutos u horas. Aplicar el mismo perfil a múltiples vServices reduce la repetición operacional.
TR7 puede añadir un header de depuración a las respuestas, permitiendo a un desarrollador u operador ver en el panel de Red del navegador si una respuesta vino de la caché o del backend. No se necesita ninguna herramienta de log adicional para la verificación rápida — acelera la puesta en marcha y el ajuste.
Pueden definirse múltiples reglas dentro de un único perfil de caché. Cada regla se activa por condiciones de path, método, header, cookie o FX. `/assets/*` puede cachearse por un tiempo largo mientras `/api/cart` se excluye. Diferentes comportamientos de caché dentro de un vService se gestionan desde un único panel.
ETag puede habilitarse por regla. Cuando un cliente solicita el mismo objeto de nuevo y el contenido no ha cambiado, recibe una respuesta de validación en lugar del cuerpo completo. Esto reduce el consumo de ancho de banda y es especialmente efectivo para activos estáticos y respuestas de API que cambian con poca frecuencia.
Cuando la caché dinámica está activada, pueden añadirse variables personalizadas a la clave de caché. El país, tipo de dispositivo, ID de tenant, grupo de prueba A/B o un valor extraído de un JWT pueden todos convertirse en parte de la clave. La misma URL se separa limpiamente entre contextos. Esto hace que la caché sea práctica para escenarios modernos de API y SaaS.
Cuando el mismo backend sirve contenido idéntico bajo múltiples dominios, el Host puede eliminarse de la clave de caché. Dominios como `a.example` y `b.example` pueden entonces compartir el mismo objeto en caché, reduciendo la duplicación de caché. Esta opción solo debe usarse cuando el contenido es genuinamente compartido.
`utm_source`, códigos de campaña y parámetros de analítica pueden hacer que el mismo contenido aparezca como objetos diferentes. Con query ignore activo, estos parámetros se excluyen de la clave de caché. La misma página bajo múltiples variantes de parámetros de seguimiento ya no llega al backend repetidamente. Los ratios de aciertos para el contenido público mejoran notablemente.
Algunos clientes o bots añaden headers que intentan eludir la caché en cada solicitud. Request check ignore permite que ese comportamiento se ignore deliberadamente. El contenido estático y las respuestas de API públicas se protegen de la carga innecesaria del backend. Esta configuración debe aplicarse cuidadosamente en endpoints sensibles a la seguridad.
Un backend puede enviar erróneamente `no-store` o headers de caché demasiado restrictivos. Response check ignore permite a los operadores anular deliberadamente esos headers. Se obtienen los beneficios de la caché sin cambiar el código de la aplicación. Esta opción solo debe usarse para respuestas deterministas y seguras.
El comportamiento estándar de caché HTTP se enfoca en respuestas GET y HEAD. TR7 permite a los operadores incluir también respuestas POST en el alcance de caché. Esto es especialmente útil cuando las queries GraphQL llegan por POST. El hash del cuerpo o las variables FX relevantes pueden añadirse a la clave de caché para asegurar una separación segura.
La caché se mantiene en memoria en tiempo de ejecución. Los cambios de configuración se aplican mediante un modelo de soft-reload; no se reclama ningún endpoint de invalidación en tiempo de ejecución. Actualizar un perfil de caché o una regla refresca el comportamiento de caché relevante. Cuando el dispositivo se reinicia, la caché comienza a calentarse de nuevo desde vacío.
Cuando se alcanza el límite de tamaño de caché, los objetos menos usados o obsoletos se expulsan. Los operadores no necesitan gestionar objetos individuales manualmente. El límite de tamaño evita que la caché de un vService afecte a otros servicios. El tamaño del perfil puede aumentarse para grandes catálogos de activos.
La Caché de Respuesta debe planificarse junto con el TTL de caché, el tamaño de objeto, el diseño de claves, el modelo de invalidación y los límites de seguridad.
El tamaño máximo para un perfil de caché se define en MB; se soportan hasta 2.048 MB por perfil. Los perfiles más grandes son adecuados para grandes catálogos de activos; un límite más bajo es suficiente para cachés de respuestas de API pequeñas.
Un TTL muy corto causa thrashing de caché y disminuye el beneficio del caché. TR7 impone un mínimo de 10 segundos para evitar ciclos de llenado y vaciado innecesarios. El TTL debe ajustarse a la frecuencia de actualización de cada endpoint.
Una clave de caché mal diseñada puede devolver contenido específico de usuario o tenant en el contexto incorrecto. Cuando se necesita diferenciación por tenant, país, tipo de dispositivo o segmento de usuario, esos valores deben incluirse en las claves de caché dinámicas. Los endpoints sensibles deben excluirse del caché por defecto.
La caché está basada en memoria; comienza vacía cuando el dispositivo o servicio se reinicia. Esto elimina la complejidad de la caché persistente en disco. La caché se calienta de nuevo con la oleada de tráfico inicial.
No se reclama ningún endpoint de invalidación en tiempo de ejecución. El comportamiento de caché se gestiona editando perfiles o reglas y activando un soft reload. Para cambiar el comportamiento de un endpoint específico, actualice la regla de caché relevante.
Los cambios de perfil de caché, timeout, opción de ignorar y clave dinámica deben capturarse en el log de auditoría. Quién cambió el comportamiento de caché de qué endpoint es visible. Esto es especialmente importante para el cumplimiento y el análisis de incidentes.
Las páginas de productos y las APIs de catálogo se cachean por un período definido. El país se añade a la clave de caché para que los mercados con diferentes precios o niveles de stock reciban el contenido correcto.
Los endpoints de noticias, anuncios o contenido público pueden cachearse por unos pocos minutos. Query ignore evita que los parámetros de seguimiento bajen el ratio de aciertos.
El ID de tenant o un header personalizado se añade a la clave de caché. El mismo path se enruta de forma segura a slots de caché separados para diferentes tenants.
Incluso cuando las queries GraphQL llegan por POST, las queries deterministas pueden cachearse. El hash del cuerpo o las variables FX relevantes se añaden a la clave de caché para minimizar el riesgo de devolver una respuesta incorrecta.
Los archivos CSS, JS, imágenes y fuentes se cachean con un TTL largo. Con ETag activo, los clientes omiten la descarga completa del cuerpo cuando se solicita contenido sin cambios.
La familia User-Agent o la clase de dispositivo se añade a la clave de caché. La misma URL se mantiene en slots de caché separados para móvil y escritorio.
Perfiles de caché, reglas condicionales, claves dinámicas y opciones de anulación conformes a RFC para la caché de respuesta. Déjenos guiarle por una configuración en vivo sobre sus propios servicios.