En Black Friday, el problema de una tienda rara vez es la falta de servidores, sino la solicitud que llega al origen sin necesidad, pidiendo una página o una imagen que una copia en caché podría haber servido. Cada página servida desde el caché es una solicitud menos al backend en el momento del pico, y por eso preparar el caché para Black Friday suele dar más resultado que agregar máquinas al origen.
A continuación, verás cómo hacer esa preparación en Azion, desde lo que va al caché hasta el plan de purge para cuando cambie el precio.
¿Por qué el pico de Black Friday llega al origen?
Dos situaciones explican la mayor parte de ese tráfico. La primera es el caché vacío a medianoche, cuando la campaña abre y los primeros accesos de cada data center van todos al servidor de origen de la tienda. La segunda es un TTL demasiado corto, que hace que la copia expire y obliga a Azion a buscar de nuevo un contenido que no cambió.
Cuando ambas están resueltas, el resultado se ve en el caso de Renner, que llegó a un pico de 899 mil solicitudes por segundo en Black Friday y, según el caso de éxito, solo un pequeño porcentaje de ellas llegó a su infraestructura de origen.
Cada viaje al origen también suma tiempo de respuesta, y la latencia en el e-commerce reduce la conversión aunque la tienda siga en línea. Parte de ese tráfico ni siquiera viene de clientes, sino de bots, que también conviene filtrar antes del pico.
¿Qué puede ir al caché y qué no?
El criterio es simple: va al caché lo que es igual para todos, y queda fuera lo que cambia con cada visitante. La vitrina, las categorías, las páginas de producto, las imágenes, el CSS, el JavaScript y las fuentes son iguales para cualquier visitante y concentran el tráfico de la campaña. El carrito, el checkout y el login cambian en cada sesión y siguen yendo al origen, y el post sobre cómo evitar fallos en el checkout durante picos de tráfico muestra cómo proteger esa parte del recorrido.
En Azion, esta separación es segura por defecto, porque Cache no guarda nada hasta que una regla de Rules Engine aplica una configuración de caché a una ruta. Tú incluyes lo que se puede compartir, ruta por ruta, y lo que ninguna regla menciona sigue yendo al origen.
| Contenido | Ejemplo de ruta | ¿Va al caché? |
|---|---|---|
| Imágenes, CSS, JS y fuentes | /static/*, /images/* | Sí |
| Vitrina y páginas de categoría | /, /ofertas/*, /c/* | Sí |
| Páginas de producto | /p/* | Sí, si el precio y el inventario no están personalizados |
| Carrito, checkout y login | /carrito/*, /checkout/*, /login | No |
Si la página de producto muestra un precio o un inventario distinto por cookie, necesita variar el caché por esa cookie, lo que requiere Application Accelerator, o cargar esa parte con una llamada separada que no pasa por el caché, como explica el post sobre por qué el caché tradicional falla en el momento de la compra.
¿Qué TTL de caché usar en la semana del evento?
El TTL es el tiempo que se guarda la copia, y cada configuración de caché de Azion tiene dos, uno para el caché de Azion y otro para el navegador. Con la opción Honor cache policies, el tiempo de vida lo definen los encabezados de caché HTTP Cache-Control y Expires que envía el origen, y con Override cache behavior vale el Max Age que tú definas, como explica la página de expiración y actualización (en inglés).
Para Black Friday, Override es la opción más predecible, y también es obligatoria para activar Tiered Cache. Un punto de partida para una tienda típica:
| Contenido | TTL de caché sugerido para la semana | Observación |
|---|---|---|
| Imágenes, CSS, JS y fuentes | Días | Purge cuando cambie el archivo |
| Vitrina y páginas de categoría | Minutos | Con Stale cache activado |
| Páginas de producto | Minutos | Purge cuando cambie el precio |
| Ofertas relámpago | Pocos segundos | Requiere Application Accelerator |
En las páginas con precio, conviene mantener corto el TTL del navegador, para que quien vuelve a la página no vea un precio viejo después de un purge.
Sin Application Accelerator, el Max Age mínimo es de 60 segundos. Con él, puedes hacer micro caching de páginas que cambian mucho, como una vitrina de ofertas relámpago con 10 segundos de TTL. Y cuando varias solicitudes por el mismo objeto llegan al mismo tiempo sin copia en el caché, Azion abre una sola conexión con el origen para todas ellas.
¿Cómo reduce Tiered Cache la carga en el origen?
Tiered Cache (en inglés) crea una segunda capa de caché antes del origen, alojada en la región que define la topología de la configuración de caché. Cuando un data center no tiene el objeto, consulta esa capa antes de ir al origen, y un objeto buscado una vez en el origen pasa a atender a los demás data centers desde allí, sin que el primer acceso en cada uno se convierta en una solicitud al servidor de la tienda.
Para activarlo, la configuración de caché debe usar Override cache behavior y tener un Max Age de al menos 3 segundos con Application Accelerator, o de 60 segundos sin él, que es el mínimo de cualquier configuración de caché. Está incluido en todos los planes, a cambio de un salto extra cuando la primera capa no tiene el objeto, y el artículo ¿Qué es Tiered Caching? explica esta arquitectura con más detalle.
¿Qué pasa con el caché si el origen se cae?
Con Stale cache activado, Azion sigue sirviendo la última copia que tiene cuando el origen responde con un error 5xx, tarda más del límite o está fuera de línea, y también mientras busca una versión nueva, así que el visitante sigue viendo la vitrina en lugar de una página de error.
Esta protección tiene una ventana de 300 segundos por defecto, o el valor de stale-while-revalidate que envíe el origen cuando la configuración usa Honor cache policies, y pasada la ventana las páginas expiradas vuelven a depender del origen. Para caídas más largas, Azion permite distribuir el tráfico entre dos o más orígenes con Load Balancer.
Verifica que Stale cache esté activado, porque las configuraciones creadas por la API o por la CLI empiezan con él desactivado. En las respuestas, el estado STALE indica que el origen falló y se sirvió la copia expirada, y UPDATING, que una versión nueva está en camino.
¿Cómo calentar el caché antes del pico?
Calentar el caché, o hacer el precalentamiento de caché, es adelantar el primer acceso a cada página para que no le toque al visitante, y la Azion CLI tiene un comando para eso, azion warmup (en inglés). Empieza en una URL base, lee los enlaces de cada página que recibe y solicita cada URL nueva que encuentra, hasta que la cola se vacía o el comando alcanza el límite de URL.
Por defecto, el comando envía 2 solicitudes al mismo tiempo, procesa hasta 1.500 URL y espera hasta 8 segundos por cada una. La URL base puede incluir una ruta, para calentar solo la sección de la campaña con límites ajustados a ella (el --timeout se cuenta en milisegundos):
Al final, un resumen cuenta las URL que salieron bien y las que fallaron. Como cada página fuera del caché va al origen, ejecuta el comando en un horario de poco tráfico y aumenta el --max-concurrent de a poco.
El calentamiento rinde más con Tiered Cache activado, porque un data center que no tiene el objeto consulta esa capa antes de ir al origen, y una página calentada en ella pasa a servirse desde allí a los demás data centers. El horario también tiene que coincidir con el TTL, por eso el calentamiento de madrugada sirve para lo que se queda mucho tiempo en caché, como imágenes y archivos estáticos, mientras que las páginas con TTL corto piden un calentamiento justo antes de que abra la campaña y después de cada purge.
¿Cómo actualizar el precio sin vaciar todo el caché?
En Black Friday, el precio cambia de hora en hora, y Real-Time Purge (en inglés) elimina objetos del caché por URL, por cache key o por wildcard, desde Console, la API o la CLI. Lo más seguro es dejarlo listo en un script o en el pipeline que publica los precios.
Con Tiered Cache activado, limpia primero la capa de Tiered Cache, que solo acepta purge por cache key, y después el caché principal, porque en el orden inverso un data center puede volver a buscar la copia vieja que todavía estaba en Tiered Cache:
La cache key de una página aparece en el encabezado x-cache-key de la respuesta cuando la solicitud se envía con Pragma: azion-debug-cache, y ese es el valor que necesita el purge de Tiered Cache. En la cache key por defecto, el scheme, el host y el path aparecen juntos, sin separador, como en el ejemplo anterior. Si la página varía por cookie, el purge por URL no alcanza esas copias, y hay que purgar cada variación por cache key o usar un wildcard que termine en @@*.
Un purge por URL o cache key acepta hasta 50 objetos por solicitud y 10.000 cada 60 segundos, y el purge por wildcard acepta una expresión por solicitud y 2.000 solicitudes cada 24 horas. Para un cambio de precios masivo, esto favorece limpiar una sección entera por wildcard, como www.tutienda.com/ofertas/*, y reservar el purge por URL para productos sueltos.
El purge entra en una cola y se propaga por la infraestructura distribuida de Azion, y, después de él, ejecutar azion warmup en la sección purgada ayuda a poner la copia nueva en el caché antes de que el tráfico vuelva a pedirla.
¿Cómo saber cuánto tráfico viene del caché?
El offload, la parte del tráfico servida sin ir al origen, es el número que resume esta preparación. En Real-Time Metrics (en inglés), en la pestaña Applications, filtra el panel por el host de la tienda y sigue el gráfico Edge Offload y los totales de Saved Data y Missed Data. En el panel Requests, los equivalentes son Requests Offloaded, Saved Requests y Missed Requests.
Durante el pico, el gráfico de Missed Requests muestra las solicitudes que el data center no respondió desde su propio caché. Un salto justo después de un purge es esperable, mientras que un nivel alto y constante suele indicar una ruta sin regla de caché o una página que varía por algo que el caché no considera. Con Tiered Cache activado, lo que realmente llega al origen aparece en la pestaña Tiered Cache.
Para probar esta configuración antes del pico, crea una cuenta gratis en el plan Hobby y arma las reglas de caché de tu aplicación, o habla con un especialista de Azion para planear el caché de tu tienda para Black Friday.
Preguntas frecuentes
¿Qué es calentar el caché?
Es solicitar las páginas antes de que lleguen los visitantes, para que la primera copia ya esté guardada cuando empiece el pico. En Azion, azion warmup, de la Azion CLI, lo hace a partir de una URL base, siguiendo los enlaces de cada página.
¿Qué TTL usar para las páginas de producto?
Minutos, en la mayoría de las tiendas, con purge cada vez que cambie el precio y un TTL de navegador corto. Si la página necesita un TTL por debajo de 60 segundos, eso requiere Application Accelerator.
¿Qué pasa con el caché si el origen se cae?
Con Stale cache activado, Azion sigue sirviendo la última copia hasta 300 segundos por defecto, o durante el valor de stale-while-revalidate que envíe el origen.
¿Cómo actualizar el precio sin vaciar todo el caché?
Usa Real-Time Purge por URL o cache key para productos sueltos, y por wildcard para una sección entera. Con Tiered Cache activado, limpia primero Tiered Cache y después el caché principal.
¿Cómo saber cuánto tráfico viene del caché?
En Real-Time Metrics, el gráfico Edge Offload de la pestaña Applications muestra la parte de los datos servida desde el caché, y Requests Offloaded muestra la parte de las solicitudes.
¿Cómo configurar el caché para Black Friday en Azion?
Azion es una plataforma serverless que ejecuta aplicaciones en una infraestructura distribuida de data centers. El caché se configura con reglas en Rules Engine, usando el comportamiento Set Cache Policy, y Tiered Cache y Stale cache se activan en las configuraciones de caché de la aplicación.