Qué es la invalidación de caché de CDN

Introducción al almacenamiento en caché de CDN

Una Content Delivery Network (CDN) funciona almacenando en caché copias de tu contenido en servidores edge repartidos por todo el mundo y sirviéndolas a los usuarios desde el servidor más cercano, en lugar de que cada petición vaya a tu servidor de origen. Esto reduce drásticamente la latencia y acelera la carga del sitio para los usuarios, independientemente de su ubicación. Sin embargo, el almacenamiento en caché trae consigo un reto fundamental: cómo garantizar que los usuarios vean siempre la versión más reciente del contenido cuando realizas cambios en el sitio.

La invalidación de caché es el proceso de eliminar o reemplazar contenido obsoleto de la caché de la CDN. Phil Karlton dijo una vez que en informática solo hay dos cosas difíciles: nombrar las cosas y la invalidación de caché. Esta afirmación ilustra a la perfección lo compleja que es la gestión de la caché, porque cada decisión equivocada puede hacer que los usuarios vean contenido obsoleto o que el servidor de origen se sobrecargue innecesariamente porque la caché se purga de forma demasiado agresiva.

Cómo funciona la caché de la CDN

Cuando un usuario solicita por primera vez un recurso que no está en caché, la CDN reenvía la petición al servidor de origen, obtiene la respuesta y almacena una copia en su servidor edge. Cada petición posterior del mismo recurso desde el mismo servidor edge se sirve directamente desde la caché sin contactar con el origen. El servidor de origen controla el comportamiento de la caché mediante cabeceras HTTP como Cache-Control, Expires, ETag y Last-Modified.

Cabeceras HTTP clave para el almacenamiento en caché

• Cache-Control: max-age=3600: el recurso está fresco durante los próximos 3600 segundos (1 hora)
• Cache-Control: s-maxage=86400: específico para cachés compartidas (CDN), con prioridad sobre max-age
• Cache-Control: no-cache: la caché debe revalidar con el origen antes de servir
• Cache-Control: no-store: el recurso nunca debe almacenarse en caché
• ETag: identificador único de la versión del recurso para la revalidación
• Vary: determina según qué cabeceras difieren las versiones cacheadas

Entender estas cabeceras es clave porque definen las reglas con las que la CDN decide si sirve la versión cacheada o solicita una nueva al servidor de origen. Unas cabeceras mal configuradas son la causa más habitual de problemas con contenido obsoleto o con peticiones innecesariamente frecuentes al origen.

Purga de caché: limpieza manual de la caché

La purga de caché es la forma más directa de eliminar contenido de la caché de la CDN. La mayoría de los proveedores de CDN ofrecen una API y un panel para activar manualmente las operaciones de purga. Puedes limpiar una sola URL, un grupo de URL por patrón (purga con comodín) o la caché completa de todos los recursos. Cada enfoque tiene ventajas e inconvenientes según la situación.

Tipos de operaciones de purga

La purga de una sola URL es el método más preciso y rápido porque apunta exactamente a un recurso. Úsala cuando actualices una página o un archivo. La purga con comodín elimina todos los recursos que coincidan con un patrón determinado; por ejemplo, /blog/* elimina de la caché todas las páginas del blog. Esto es útil cuando actualizas un número mayor de páginas pero no quieres limpiar la caché completa. La purga total elimina absolutamente todo de la caché y solo debería usarse en situaciones urgentes, porque aumenta temporalmente la carga del servidor de origen mientras se reconstruye la caché.

Las operaciones de purga suelen propagarse por la red de la CDN en un plazo de 1 a 30 segundos, según el proveedor y el tamaño de la red. La purga en la red de Cloudflare se propaga en unos 30 segundos a nivel global, mientras que AWS CloudFront puede necesitar hasta 15 minutos para las invalidaciones con comodín. Ten siempre en cuenta este retardo cuando realices cambios en producción y compruebes si la nueva versión es visible.

Estrategias de TTL

El Time-To-Live (TTL) determina durante cuánto tiempo la CDN considera fresco el contenido cacheado antes de solicitar una nueva versión al origen. Ajustar correctamente el TTL es un equilibrio entre rendimiento (TTL más largo = menos peticiones al origen) y frescura del contenido (TTL más corto = los cambios se ven antes). No existe un TTL universalmente correcto, porque depende del tipo de contenido y de la frecuencia con la que cambia.

TTL recomendado por tipo de contenido

• Recursos estáticos (JS, CSS, fuentes): 1 año (31536000 s) con versionado de archivos
• Imágenes: 30 días (2592000 s) con revalidación por ETag
• Páginas HTML: de 5 minutos a 1 hora según el contenido dinámico
• Respuestas de API: de 0 a 60 segundos según los datos
• Favicon y robots.txt: 1 día (86400 s)

La directiva stale-while-revalidate es una estrategia excelente que permite a la CDN servir contenido obsoleto a los usuarios mientras solicita simultáneamente una nueva versión al origen en segundo plano. Esto significa que el usuario nunca espera al servidor de origen, pero verá la nueva versión en la siguiente petición. Por ejemplo, Cache-Control: max-age=60, stale-while-revalidate=3600 significa que el contenido está fresco durante 60 segundos, pero puede servirse desde la caché durante la siguiente hora mientras se actualiza en segundo plano.

Versionado de recursos

El versionado de recursos es la estrategia más elegante para resolver el problema de la invalidación de caché, porque elimina por completo la necesidad de operaciones de purga explícitas. En lugar de cambiar el contenido del archivo en la misma URL, cada nueva versión recibe una URL nueva, lo que significa que la CDN sirve automáticamente la nueva versión porque la trata como un recurso completamente nuevo que aún no está en caché.

Métodos de versionado

El hash de contenido en el nombre del archivo es el método más popular. Herramientas de build como Webpack, Vite y Next.js añaden automáticamente un hash de contenido al nombre del archivo; por ejemplo, style.a1b2c3d4.css. Cuando el CSS cambia, el hash cambia y se genera un nuevo archivo con un nombre nuevo. La versión antigua permanece en caché, pero ya nadie la referencia porque el HTML ahora apunta al nuevo archivo.

El versionado mediante query string (style.css?v=1.2.3) es un enfoque más sencillo pero menos fiable, porque algunos proveedores de CDN ignoran las query strings al cachear. Úsalo solo si no puedes cambiar el nombre del archivo. El versionado por ruta (/v2/style.css) es otra opción que funciona de forma fiable con todos los proveedores de CDN, pero requiere más configuración en el servidor.

Cuándo invalidar la caché

Saber cuándo invalidar la caché es tan importante como saber cómo hacerlo. Los escenarios más habituales que requieren invalidación incluyen desplegar una nueva versión del sitio en el servidor de hosting, corregir un error crítico en el contenido, eliminar contenido sensible publicado por accidente y cambiar precios o disponibilidad de productos en una tienda online. En todos estos casos, los usuarios deben ver el contenido actualizado lo antes posible.

Buenas prácticas de invalidación

• Automatiza: integra la purga de caché en el pipeline de CI/CD para invalidar automáticamente en cada despliegue
• Sé preciso: apunta a URL específicas en lugar de hacer una purga total siempre que sea posible
• Usa versionado: para recursos estáticos elimina por completo la necesidad de invalidación manual
• Monitoriza: controla el cache hit ratio para detectar problemas de configuración
• Prueba: comprueba las cabeceras con curl -I para confirmar que el almacenamiento en caché funciona como se espera
• Documenta: registra los valores de TTL y la estrategia de invalidación para cada tipo de contenido

Problemas habituales y soluciones

Uno de los problemas más comunes es el llamado contenido obsoleto (stale content), en el que los usuarios ven contenido desactualizado a pesar de los cambios que has hecho en el servidor de origen. La causa suele ser un TTL demasiado largo sin un mecanismo de invalidación. La solución es la combinación de un TTL razonable con operaciones de purga automatizadas en el despliegue. Otro problema habitual es la estampida de caché (cache stampede), en la que, tras expirar el TTL de un recurso popular, cientos de peticiones simultáneas golpean a la vez el servidor de origen. La solución es la coalescencia de peticiones, en la que la CDN envía una sola petición al origen mientras retiene todas las demás hasta recibir la respuesta.

El problema de tener distintas versiones del contenido en distintos servidores edge (inconsistencia de caché) surge porque una operación de purga no puede propagarse a todos los servidores de forma simultánea. Durante el breve periodo posterior a la purga, algunos usuarios verán la versión antigua y otros la nueva. Para los cambios críticos, utiliza el mecanismo de versionado de URL, que garantiza la consistencia porque cada usuario accede a una versión del recurso definida con exactitud.