Un CDN coloca puntos de entrega cerca de los consumidores y puede reutilizar respuestas sin repetir el recorrido hasta el origen. Reduce latencia y trabajo del origen cuando la respuesta es cacheable. También introduce copias distribuidas con reglas de identidad, frescura y acceso que deben formar parte del contrato del producto.
Una imagen pública y un documento privado necesitan políticas distintas aunque ambos sean archivos. El diseño comienza por qué puede compartirse, entre quiénes y durante cuánto tiempo, y qué camino atiende los misses.
Cache key: identidad de una respuesta
La cache key determina qué peticiones pueden reutilizar la misma entrada. Suele partir del host y la ruta, y puede incluir parámetros de consulta, cabeceras o cookies seleccionadas. Método HTTP, variantes de compresión, idioma y cualquier otro dato que cambie el resultado deben resolverse según las capacidades del CDN. No basta con observar que dos URLs tienen la misma ruta.
Por ejemplo, /report devuelve contenido diferente según el tenant autenticado. Si la respuesta se guarda en una caché compartida y la identidad no está correctamente aislada, otro usuario podría recibirla. Incluir una cabecera en la clave solo ayuda si su valor proviene de una identidad confiable y se valida el acceso; no sustituye la autorización. Para contenido privado, el punto de partida prudente es evitar caché compartida salvo que exista un contrato explícito y comprobado.
Las claves demasiado amplias pueden mezclar respuestas. Las demasiado específicas fragmentan la caché: incluir cada cookie o parámetro de seguimiento reduce reutilización y aumenta misses. Hay que distinguir datos que cambian la respuesta de datos que solo deben enviarse al origen. La política de clave y la de forwarding necesitan revisarse juntas.
Hits, misses y origen
--- config: look: handDrawn --- flowchart TD client["Cliente"] --> edge["Borde del CDN<br/>Política de acceso y clave de caché"] edge --> fresh{"¿Entrada reutilizable?"} fresh -->|"Acierto de caché"| response["Entregar respuesta permitida"] fresh -->|"Fallo de caché o revalidación"| protect["Acceso al origen acotado"] protect --> origin["Origen<br/>Autorización y contenido"] origin -->|"Respuesta cacheable + validadores"| fill["Guardar variante seleccionada"] fill --> response response --> client release["Publicación de recurso versionado"] -->|"URL nueva"| edge purge["Solicitud de invalidación"] -.->|"Debe observarse la propagación"| edge
El origen sigue siendo responsable de su autorización y contenido. Debe impedir accesos directos que evadan controles previstos en el borde cuando la arquitectura requiere ese perímetro; el mecanismo depende del servicio. Una URL difícil de adivinar no constituye control de acceso.
Un miss añade el recorrido al origen y puede coincidir en muchos puntos de presencia. Una capa de shield, agrupación de peticiones o caché intermedia puede reducir ese fanout, según el producto. También necesita límites de concurrencia y una política de fallo: una purga amplia o despliegue que enfría la caché no debe saturar el origen.
TTL, validadores y contenido anterior
Las cabeceras HTTP describen reglas como max-age, s-maxage, private y no-store; el CDN puede imponer límites o políticas adicionales. Debe verificarse la combinación real. private comunica que una caché compartida no debe almacenar la respuesta; no-store pide no almacenarla. Ninguna cabecera borra automáticamente una copia que ya se distribuyó bajo otra política. En CloudFront, un minimum TTL mayor que cero puede sobreponerse incluso a private, no-store o no-cache; debe ser cero para respetar esas directivas del origen.
El TTL limita cuándo una entrada puede reutilizarse sin revalidación bajo esa política. No demuestra que el origen no cambió. Una respuesta generada a partir de datos antiguos puede recibir un TTL nuevo. Los validadores, como ETag, permiten consultas condicionales, pero requieren que el origen represente correctamente la versión del contenido y sus variantes.
stale-while-revalidate puede permitir entregar una copia anterior mientras se actualiza; stale-if-error puede permitirla durante ciertos fallos. Ambos necesitan ventanas de obsolescencia aceptadas por el producto y soporte verificado. Precio, inventario y permisos no deben depender de una copia si la operación requiere validar el estado actual. La vista de disponibilidad y la reserva de un asiento ilustran esa separación.
Versiones e invalidación
Para assets que realmente permanecen inmutables, una ruta con versión o hash, como /assets/app.<hash>.js, permite publicar una nueva URL sin esperar a que desaparezca la versión anterior. El hash debe corresponder al contenido y el objeto anterior conservar sus bytes. Cambiar el contenido bajo esa misma URL rompe el supuesto. El documento que referencia las versiones necesita su propia política de frescura.
La invalidación solicita retirar entradas existentes. Debe tratarse como una operación distribuida cuyo resultado y propagación se observan. Que la API acepte la solicitud no demuestra que todos los consumidores hayan dejado de usar la copia: puede haber cachés de navegador, proxies o respuestas ya entregadas. Si la respuesta de la API se pierde, hay que consultar o reconciliar el estado antes de asumir éxito o ausencia de la operación.
También debe probarse una carrera entre un llenado antiguo y una invalidación. El contrato del proveedor determina cómo procesa esos eventos; no debe suponerse que una purga vuelve atómica una actualización del origen. Para una retirada sensible, se necesita un mecanismo de acceso o revocación compatible con el requisito, además de observar la purga.
CloudFront puede conservar contenido privado en edge cache si valida la URL o política firmada antes de servirlo. Esto requiere configurar acceso y cacheabilidad como decisiones distintas, sin mezclar respuestas personalizadas. Las URLs firmadas o cookies firmadas pueden limitar acceso cuando el producto las valida. Sus expiraciones, claves y posible revocación deben definirse. Copiar el enlace permite a otra persona usar las facultades que incorpore durante su vigencia, salvo controles adicionales. Versionar la ruta o invalidarla no reemplaza ese modelo de acceso.
Qué verificar
Hay que comparar peticiones que difieren en idioma, tenant, autorización, cookies y parámetros relevantes. Ninguna debe reutilizar una respuesta incompatible. Debe comprobarse además el acceso directo al origen, una caída con caché fría y el comportamiento cuando el origen devuelve errores.
Las señales útiles incluyen hit ratio por ruta y variante, bytes entregados, latencia del consumidor, solicitudes y concurrencia en el origen, errores y edad de respuestas. El hit ratio agregado puede ocultar rutas caras con muchos misses. La evaluación económica necesita esas unidades y el coste real de transferencias y solicitudes.
El ensayo de publicación debe actualizar el documento y sus assets, observar una invalidación y comprobar clientes con una versión anterior. El resultado esperado especifica qué contenido anterior sigue siendo válido y cómo se recupera el servicio sin sobrecargar el origen.