Tiered Cache | Cómo Reducir la Carga en el Origin en Checkout y APIs

El cache tradicional protege el origin en condiciones normales. Pero durante picos de tráfico — cuando la checkout performance está más en riesgo, no es suficiente. Tiered Cache añade capas intermedias entre el usuario y el backend, consolidando solicitudes y aumentando el cache hit ratio. Selective Caching complementa esta estrategia definiendo con precisión qué debe ser cacheado — y con qué regla. Juntos, reducen costos, protegen el origin y mantienen la conversión estable bajo demanda extrema.

Introducción

El cache tradicional resuelve bien el problema de contenido estático. Para e-commerce a escala, no es suficiente.

Durante picos de tráfico, no basta almacenar respuestas cerca del usuario. Necesita decidir en cuántas capas distribuir este cache y qué reglas determinan qué será almacenado. Sin este control, el origin recibe carga que podría evitarse — y el checkout comienza a degradarse exactamente cuando la intención de compra está en su pico.

Tiered Cache y Selective Caching responden estas dos preguntas. Este artículo explica cómo funciona cada estrategia, cuándo combinarlas y qué impacto real tienen en la performance del checkout y APIs transaccionales.

1. ¿Qué es Tiered Cache?

Tiered Cache es una estrategia de cache en múltiples capas que introduce un nivel intermedio de almacenamiento entre los puntos de presencia distribuidos y el servidor de origin.

En una arquitectura tradicional, cuando un nodo en infraestructura distribuida no encuentra datos en cache, consulta directamente al origin. En una arquitectura con Tiered Cache, primero consulta una capa intermedia — un cache centralizado compartido entre múltiples puntos.

Esto cambia el comportamiento del tráfico significativamente:

• solicitudes de múltiples puntos geográficos se consolidan
• el origin recibe muchas menos consultas directas
• el cache hit ratio global aumenta
• el costo de egress baja

Tiered Cache responde una pregunta específica: “¿En cuántas capas debo distribuir el cache para reducir la carga del origin?“

2. Cómo funciona Tiered Cache en la práctica

El flujo de una solicitud en una arquitectura con Tiered Cache funciona así:

Nivel 1 — Punto de presencia local La solicitud llega al nodo más cercano al usuario. Si el dato está en cache local, se entrega inmediatamente.

Nivel 2 — Capa intermedia (Tiered Cache) Si el cache local no tiene el dato, el nodo consulta la capa intermedia antes de ir al origin. Esta capa es compartida entre múltiples puntos de presencia.

Nivel 3 — Origin Solo si la capa intermedia tampoco tiene el dato, la solicitud llega al backend.

Este modelo tiene dos efectos prácticos inmediatos:

Consolidación de solicitudes Múltiples nodos que necesitarían consultar el origin de forma independiente ahora comparten una única respuesta. El origin deja de recibir llamadas redundantes de diferentes puntos.

Aumento del cache hit ratio Datos que no están en cache local tienen una segunda oportunidad de encontrarse antes de llegar al origin. Esto aumenta la proporción de solicitudes resueltas sin consultar el backend.

3. ¿Qué es Selective Caching?

Selective Caching — también llamado cache granular o cache avanzado — es la capacidad de definir qué debe ser cacheado basándose en información específica de la solicitud HTTP.

A diferencia del cache “todo o nada”, Selective Caching usa Advanced Cache Keys para segmentar el contenido almacenado:

Cache por header Almacena versiones diferentes de una respuesta basándose en headers como Device-Type, Accept-Language o User-Segment.

Cache por cookie Acelera fragmentos de páginas personalizados sin mezclar datos de diferentes sesiones.

Cache por query string Trata parámetros de búsqueda, filtros o segmentación como criterio de diferenciación del cache.

Selective Caching responde una pregunta diferente a Tiered Cache: “¿Qué exactamente debo cachear — y con qué regla?”

Esta distinción es importante para evitar superposición con otras estrategias del cluster. Micro Caching responde “¿por cuánto tiempo cachear?”. Tiered Cache responde “¿en cuántas capas?”. Selective Caching responde “¿con qué criterio de selección?”. Son preguntas diferentes y estrategias complementarias.

4. Cuándo usar cada estrategia

Tabla comparativa

Cuándo usar Tiered Cache

• operaciones con múltiples puntos geográficos de acceso
• datos con alta concurrencia y baja variación
• picos de tráfico con patrón de solicitudes concentradas
• cuando el costo de egress necesita reducirse

Cuándo usar Selective Caching

• respuestas que varían por segmento de usuario
• APIs con comportamiento diferente por dispositivo o localización
• fragmentos de página con personalización parcial
• flujos que necesitan cache sin mezclar estado de sesión

Cuándo combinar ambos

Combine Tiered Cache y Selective Caching cuando necesite:

• alta eficiencia en múltiples capas
• control granular sobre qué almacena cada capa

En e-commerce de alta escala, esta combinación es el estándar para proteger el origin sin sacrificar personalización.

5. Qué puede y qué no puede ser cacheado con estas estrategias

6. Impacto real en checkout y APIs

Protección del origin

Cuando la mayoría de las solicitudes se resuelven en capas distribuidas, los sistemas de origin solo manejan operaciones transaccionales esenciales. El crecimiento de tráfico deja de traducirse directamente en estrés en el backend.

Reducción de costo de transferencia

Al servir más datos en capas intermedias, los costos de transferencia de datos bajan significativamente. Lojas Renner, después de migrar a la infraestructura distribuida de Azion, registró una reducción del 67% en costos de transferencia de datos.

Aumento del cache hit ratio

Marisa entrega más del 85% de sus datos directamente a través de infraestructura distribuida, ahorrando en promedio 4.3 TB de ancho de banda por día — con páginas más rápidas, menores costos y conversiones estables incluso durante períodos de alta demanda.

Estabilidad de P99

Al consolidar solicitudes en capas intermedias y reducir la presión sobre el origin, Tiered Cache contribuye directamente a mantener la latencia estable incluso bajo picos — incluyendo la cola de la distribución, donde están los usuarios más afectados.

7. Resiliencia programable en la práctica

Tiered Cache y Selective Caching se vuelven aún más poderosos cuando son parte de una estrategia de resiliencia programable.

Esto significa que usted puede:

Ajustar dinámicamente durante campañas Modificar políticas de cache en tiempo real, sin nuevos deploys. Durante un evento de Black Friday, esto puede ser la diferencia entre reaccionar a un incidente a las 11 PM o tener la plataforma ajustándose automáticamente.

Combinar con stale-while-revalidate Mientras el dato se revalida en segundo plano, el usuario recibe la versión en cache sin percibir ninguna degradación. En escenarios de falla parcial del origin, esto preserva la disponibilidad del checkout.

Purge por key en lugar de purge total Cuando un precio cambia o un producto se agota, no hay razón para invalidar el cache de toda la aplicación. Con invalidación por key, solo limpia los fragmentos afectados — sin impactar la performance del resto.

// Ejemplo: invalidación por tag con Azion Lib
import { purgeWildCard } from 'azion/purge';

async function purgePatterns(patterns, label) {
  const { data, error } = await purgeWildCard(patterns);
  if (error) {
    console.error(`Purge failed for ${label}:`, error);
    return { success: false, error };
  }
  return { success: true, invalidated: data?.items };
}

Claves de cache avanzadas integradas en el workflow Las reglas de cache pueden definirse en código y actualizarse en tiempo real, permitiendo que los equipos prueben estrategias de personalización, ajusten políticas por segmento y automaticen invalidaciones basadas en stock o promociones.

8. Ejemplo real: Lojas Renner en Black Friday

Lojas Renner es uno de los casos más expresivos de uso de infraestructura distribuida para proteger el checkout durante picos de tráfico en Brasil.

Black Friday requería una arquitectura capaz de sostener picos masivos de acceso sin degradar el checkout para millones de consumidores. Para eliminar cuellos de botella centralizados, Renner migró sus aplicaciones a la infraestructura distribuida de Azion, acercando la ejecución a los usuarios y asegurando que solo solicitudes transaccionales críticas llegaran a los sistemas de origin.

Los resultados fueron:

Black Friday dejó de ser una prueba de estrés de infraestructura y se convirtió en un evento de ingresos predecible.

→ Lea el caso completo de Renner

9. FAQ

¿Qué es Tiered Cache?

Es una estrategia de cache en múltiples capas que añade un nivel intermedio entre los puntos de presencia distribuidos y el servidor de origin, consolidando solicitudes y reduciendo llamadas directas al backend.

¿Tiered Cache es diferente de CDN tradicional?

Sí. El cache en infraestructura distribuida con capas programables permite control granular sobre qué se almacena, por cuánto tiempo y con qué criterio de invalidación. La arquitectura centralizada tradicional no ofrece este nivel de control sobre flujos transaccionales.

¿Selective Caching compromete datos del usuario?

No, si se configura correctamente. El uso de Advanced Cache Keys asegura que versiones diferentes del mismo recurso se almacenen separadamente — previniendo que datos de una sesión sean entregados a otro usuario.

¿Cómo combinar Tiered Cache con Micro Caching?

Tiered Cache define las capas de almacenamiento. Micro Caching define el TTL corto para datos dinámicos. Son estrategias complementarias: puede aplicar Micro Caching dentro de una arquitectura con Tiered Cache para datos de alta variación.

¿Cuándo usar purge por key en lugar de purge total?

Siempre que sea posible. El purge total invalida el cache de toda la aplicación — incluyendo contenido que no cambió. El purge por key remueve solo los fragmentos afectados por el cambio, manteniendo el resto de la aplicación acelerada.

¿Cómo ayuda Tiered Cache en flash sales?

En flash sales, múltiples usuarios acceden a los mismos recursos simultáneamente. Tiered Cache consolida estas solicitudes en capas intermedias, reduciendo drásticamente la presión sobre el origin exactamente cuando el tráfico está en su pico.

Conclusión

Tiered Cache y Selective Caching no son optimizaciones aisladas. Son parte de una estrategia integrada de protección del origin y control de tráfico para flujos transaccionales a escala.

Tiered Cache resuelve cuántas capas distribuir. Selective Caching resuelve qué cachear y con qué regla. Juntos, aumentan el cache hit ratio, reducen costos y mantienen la conversión estable incluso cuando el tráfico se dispara.

En e-commerce de alta escala, la pregunta no es si debe usar cache en capas. La pregunta es si tiene suficiente control sobre cómo se comporta ese cache — y si es lo suficientemente programable para acompañar la velocidad del negocio.

Próximos pasos

Conozca la solución de Cache en Capas de Azion: https://www.azion.com/en/products/cache/

Vea cómo implementar Tiered Cache y Selective Caching en su checkout: Hable con un especialista de Azion