¿Cómo funciona realmente la arquitectura de una CDN: origen, PoPs de borde, jerarquía de caché e invalidación?
Una CDN es una capa de caché distribuida globalmente que intercepta peticiones antes de que tu origen las vea: sus niveles explican tanto su velocidad como sus dolores de cabeza de invalidación.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo funciona realmente la arquitectura de una CDN: origen, PoPs de borde, jerarquía de caché e invalidación?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Qué problema resuelve realmente una CDN
Cada byte que un usuario descarga tiene que recorrer la distancia física entre donde está almacenado y donde está el usuario, y esa distancia es latencia que no se puede optimizar con código más rápido — solo con menos distancia. Una CDN (red de entrega de contenido) resuelve esto manteniendo copias de las respuestas en servidores repartidos por el mundo, cerca de los usuarios, para que una petición desde Tokio no necesite ir y volver hasta un origen en Virginia cada vez. Esa misma capa, de paso, protege al origen del tráfico por completo: un sitio bien cacheado puede servir más del 95% de las peticiones sin que el origen las vea jamás, lo cual es tanto una historia de capacidad y resiliencia como de latencia.
#Anatomía: origen, PoPs de borde y un escudo intermedio
El origen es la verdadera fuente de la verdad — tus servidores de aplicación o tu almacenamiento de objetos, el único lugar que puede producir una respuesta que la CDN nunca haya visto antes. Los servidores de borde, desplegados en PoPs (puntos de presencia) — cientos de instalaciones pequeñas distribuidas globalmente — son la capa más cercana a los usuarios; ahí termina la conexión TLS del cliente, y si el objeto pedido está cacheado en ese PoP, la respuesta nunca sale de él.
Entre cientos de PoPs de borde pequeños y un único origen se ubica una capa opcional pero importante, el nivel intermedio (a veces llamado "escudo" o caché "regional"): un número mucho menor de cachés regionales más grandes. Sin este nivel, cada uno de los cientos de PoPs de borde consultaría al origen de forma independiente en su primer miss para un objeto dado — cientos de peticiones simultáneas al origen por el mismo contenido. Con un nivel escudo, los PoPs de borde fallan primero hacia la caché regional; solo la caché regional (una por región, no una por PoP) llega a hablar con el origen, colapsando cientos de posibles impactos al origen en un puñado.
Dirigir a un cliente hacia un PoP cercano y saludable suele hacerse mediante direccionamiento IP anycast (la misma IP anunciada desde muchas ubicaciones, con el enrutamiento de red enviando al cliente hacia la topológicamente más cercana) o mediante DNS con conciencia geográfica.
#El camino de la petición, incluyendo un cache miss
Cada miss que llega al origen puebla las cachés en su camino de regreso, así que la siguiente petición —de cualquier usuario cerca de ese mismo PoP— se convierte en un hit. Por eso la tasa de aciertos sube rápido después de un despliegue o un arranque en frío: la primera petición por objeto y por región paga el viaje completo, todas las siguientes no.
#Claves de caché y señales de frescura
Qué se cachea realmente y bajo qué clave importa tanto como si el cacheo ocurre o no. La clave de caché por defecto es el método de la petición más la URL normalizada, pero los sistemas reales a menudo necesitan variar la respuesta cacheada según encabezados o parámetros de consulta específicos (un encabezado Vary: Accept-Encoding, por ejemplo, significa que las respuestas comprimidas y sin comprimir se cachean por separado). Incluir de más en la clave de caché —variar por un encabezado que casi siempre es igual, o por una cookie de sesión distinta para cada usuario— fragmenta la caché hasta convertirla, en la práctica, en una entrada por petición, destruyendo la tasa de aciertos.
La frescura se controla mediante encabezados de respuesta del origen: Cache-Control: max-age=300 le dice a cualquier caché que la respuesta es fresca durante 300 segundos; s-maxage anula eso específicamente para cachés compartidas como una CDN, permitiéndote mantener algo fresco más tiempo en el borde que en el navegador de un usuario final; public/private controla si las cachés compartidas pueden almacenarla siquiera; y no-store excluye una respuesta del cacheo por completo. ETag junto con If-None-Match permiten una revalidación barata — la caché puede preguntarle al origen "¿esto cambió desde esta versión?" y recibir un 304 Not Modified en lugar de volver a descargar todo el cuerpo cuando no cambió.
#Invalidación: la parte difícil
Fijar un TTL es invalidación por defecto — el contenido simplemente expira después de N segundos. Es simple y no requiere coordinación, pero significa que cada objeto cacheado queda obsoleto hasta por la duración del TTL en cada actualización, un compromiso aceptable para la mayoría del contenido, pero no para algo que debe ser correcto en cuestión de segundos (como un cambio de precio).
La invalidación activa cambia eso: una llamada a una API de purga le dice a la CDN "esta URL ya no es válida", lo cual tiene que propagarse hacia cada PoP que pudiera tener una copia — genuinamente costoso a escala global, porque es efectivamente un broadcast a cientos de ubicaciones, y hay un retraso de propagación real antes de que esté garantizado que surtió efecto en todas partes.
Las etiquetas de caché (también llamadas surrogate keys) resuelven un problema relacionado pero distinto: invalidar muchas URLs que comparten alguna propiedad en una sola llamada, en lugar de purgar cada una individualmente. Una página de producto, su respuesta de API y su fragmento de resultado de búsqueda podrían etiquetarse todas como product:1001; una sola purga de esa etiqueta invalida las tres sin necesidad de conocer cada URL de antemano.
La estrategia de invalidación más limpia suele ser evitar necesitarla del todo: URLs versionadas con huella digital (app.a1b2c3.js en lugar de app.js) significan que un despliegue nuevo produce una URL completamente nueva, así que el objeto cacheado viejo nunca necesita invalidarse — simplemente nunca vuelve a pedirse, y la URL nueva puede cachearse como efectivamente inmutable (Cache-Control: public, max-age=31536000, immutable).
#Callouts y casos límite
🧠 Check your understanding
0/3 · 0/3 answered1. ¿Qué problema resuelve un nivel de caché regional/escudo que los PoPs de borde por sí solos no pueden?
2. ¿Por qué incluir de más encabezados o cookies en la clave de caché puede destruir la tasa de aciertos?
3. ¿Qué es una estampida de caché, y qué técnica la aborda directamente?