La caché HTTP parece simple; hacer correctamente la clave de caché y el manejo de excepciones en producción es difícil.
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.
Nuestro enfoque
TR7 gestiona el comportamiento de caché a través de cuatro capas: perfiles, condiciones, claves dinámicas y anulaciones controladas.
Los perfiles de caché con nombre proporcionan cuotas por servicio
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é.
Las reglas de caché condicionales toman decisiones por endpoint
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.
Las claves de caché dinámicas evitan respuestas de contenido incorrecto
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 opciones de anulación estándar mejoran la eficiencia del caché
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.
Capacidades
La Caché de Respuesta hace que cada comportamiento — desde el perfil de caché hasta la clave dinámica — sea configurable a nivel de vService.
Los perfiles de caché con nombre centralizan la configuración de tamaño y TTL
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.
Los aciertos y fallos de caché son visibles mediante un header de respuesta
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.
La lista de reglas de caché condicional da control por endpoint
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.
El soporte ETag elimina la transferencia de datos innecesaria
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.
Las claves de caché dinámicas crean slots separados por contexto
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.
Host ignore consolida el contenido multi-dominio en un único slot de caché
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.
Query ignore evita que los parámetros de seguimiento rompan la caché
`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.
Request check ignore limita el cache busting del lado del cliente
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.
Response check ignore puede anular los headers del backend mal configurados
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.
La caché de todos los métodos soporta escenarios de POST GraphQL
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é basada en memoria se gestiona mediante soft reload
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.
Los objetos menos recientemente usados se expulsan automáticamente
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.
Profundidad operacional
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.
Tamaño de caché
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.
Timeout mínimo
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.
Seguridad de la clave de caché
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.
Comportamiento en reinicio
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.
Actualización basada en reglas
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.
Auditoría y operaciones
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.
Cuándo usarlo
Caché basada en país para catálogos de productos de e-commerce
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.
Caché de corta duración para respuestas de API públicas
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.
Aislamiento por tenant para contenido SaaS multi-tenant
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.
Caché controlada de respuestas de queries GraphQL POST
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.
Descarga del tráfico de activos estáticos del backend
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.
Caché de renderizado separado para móvil y escritorio
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.
Preguntas frecuentes
¿Cómo funcionan los headers estándar como Cache-Control y ETag con TR7?
¿Cuál es la diferencia entre las claves de caché dinámicas y el header Vary?
¿Pueden cachearse algunos endpoints mientras otros se excluyen dentro del mismo vService?
¿Cómo funciona la invalidación de caché — hay una API en tiempo de ejecución?
¿Pueden cachearse las respuestas GraphQL POST?
¿Cuáles son los valores recomendados para el tamaño de caché y el timeout?
Reduzca la carga del backend con caché de respuesta
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.