¿Qué es el caché CDN, la invalidación y el desempeño?

El caché CDN almacena copias del contenido en servidores edge cerca de los usuarios, reduciendo la latencia y la carga del servidor de origen. La invalidación de caché es el mecanismo para actualizar o eliminar ese contenido antes de su expiración natural. La combinación de un caching efectivo y una invalidación precisa determina qué tan rápido y consistente se entrega tu contenido.

Resumen rápido — El caché CDN sirve contenido desde el edge en lugar del origen, con un cache hit ratio esperado de 95-99% para assets estáticos y 70-90% para API públicas. La invalidación (purge) elimina o actualiza ese contenido antes de que expire el TTL, mediante métodos como purge manual, soft purge o invalidación basada en surrogate keys. Un caché CDN bien configurado reduce la latencia entre 60-90% y la carga del origen entre 70-95%, especialmente cuando se combinan TTL agresivos para contenido inmutable con headers como stale-while-revalidate y stale-if-error para resiliencia.

Última actualización: 2026-08-08

Cómo funciona el caché CDN

Cuando un usuario solicita contenido, la CDN verifica si existe una copia en el servidor edge más cercano. Si existe y es válida, la sirve directamente (cache hit). Si no existe o expiró, la obtiene del origen y la almacena para requests futuros (cache miss).

┌─────────────────────────────────────────────────────────────────┐
│                    Request del usuario                          │
└───────────────────────────┬─────────────────────────────────────┘
                            │
                            ▼
                   ┌─────────────────┐
                   │   Edge de la    │
                   │   CDN: verifi-  │
                   │   ca la caché   │
                   └────────┬────────┘
                            │
              ┌─────────────┴─────────────┐
              │                           │
              ▼                           ▼
        ┌───────────┐              ┌───────────┐
        │Cache Hit  │              │Cache Miss │
        │ (Sirve)   │              │(Obtiene)  │
        └─────┬─────┘              └─────┬─────┘
              │                           │
              │                           ▼
              │                   ┌───────────────┐
              │                   │   Servidor    │
              │                   │  de origen    │
              │                   └───────┬───────┘
              │                           │
              │                           ▼
              │                   ┌───────────────┐
              │                   │  Almacena en  │
              │                   │  el caché edge│
              │                   └───────┬───────┘
              │                           │
              └───────────┬───────────────┘
                          │
                          ▼
                   ┌─────────────┐
                   │  Respuesta  │
                   │  al usuario │
                   └─────────────┘

Comparación de estrategias de caché

Headers HTTP para control de caché

Cache-Control

ETag y Last-Modified

Request:
  If-None-Match: "abc123"
  If-Modified-Since: Wed, 18 Jun 2026 10:00:00 GMT

Response (sin modificar):
  HTTP/1.1 304 Not Modified

Response (modificado):
  HTTP/1.1 200 OK
  ETag: "def456"
  Last-Modified: Wed, 18 Jun 2026 12:00:00 GMT
  Cache-Control: max-age=3600

Invalidación de caché

Métodos de invalidación

Ejemplo de API de purge

# Purge completo
curl -X PURGE https://cdn.example.com/*

# Purge por surrogate key
curl -X PURGE -H "Surrogate-Key: product-123" https://api.cdn.example.com/purge

# Soft purge (permite servir contenido obsoleto mientras revalida)
curl -X PURGE -H "Soft-Purge: 1" https://cdn.example.com/page

Métricas de desempeño

Cache hit ratio

Cache Hit Ratio = (Aciertos de caché / Total de requests) × 100

Ejemplo:
- Aciertos de caché: 85,000
- Fallos de caché: 15,000
- Total: 100,000
- Hit Ratio: 85%

Benchmarks por tipo de contenido:

Time to First Byte (TTFB)

Latencia por región

Latencia típica con CDN vs sin CDN:

Señales de problemas de caché

• Cache hit ratio por debajo del 70% para contenido estático
• TTFB consistentemente por encima de 200ms para páginas cacheadas
• Picos de tráfico en el origen durante eventos
• Usuarios reportando contenido obsoleto
• Costos altos de egress del origen
• Errores 502/504 durante invalidaciones masivas

Errores comunes y cómo corregirlos

Error: TTL demasiado corto para assets versionados Corrección: Los assets con hash en el nombre pueden tener TTL de 1 año (max-age=31536000)

Error: Purge en bucle infinito (invalidar → revalidar → invalidar) Corrección: Implementa debounce o cooldown entre invalidaciones

Error: Cache-Control en conflicto (max-age + no-cache) Corrección: Usa directivas consistentes; no-cache siempre requiere revalidación

Error: Ignorar query strings en el caché Corrección: Configura la CDN para normalizar o ignorar query strings cuando sea apropiado

Error: No configurar manejadores de stale Corrección: Configura siempre stale-if-error para resiliencia

Casos de uso

E-commerce con inventario dinámico

Páginas de producto: TTL de 5 minutos + stale-while-revalidate de 1 hora. API de inventario: TTL de 30 segundos. Purge manual al actualizar precio o stock.

Portal de noticias

Artículos: TTL de 1 hora + stale-while-revalidate de 24 horas. Noticias de última hora: purge inmediato vía webhook. Homepage: TTL de 5 minutos + purge al publicar.

Dashboard SaaS

Datos públicos (planes, features): TTL de 24 horas. Dashboard del usuario: private, no-store. API de métricas: TTL de 1 minuto + stale-if-error de 5 minutos.

Video streaming

Segmentos de video: TTL de 1 año (inmutable). Playlist/manifest: TTL de 10 segundos. Geo-blocking: evaluado en el edge, sin caché.

Preguntas frecuentes

¿Cuál es la diferencia entre TTL e invalidación de caché? El TTL (Time-to-Live) define cuánto tiempo permanece el contenido en caché antes de expirar automáticamente. La invalidación elimina o actualiza el contenido antes de que expire el TTL, garantizando consistencia inmediata.

¿Cuándo debería usar stale-while-revalidate? Úsalo cuando la alta disponibilidad sea más importante que la consistencia inmediata. Los usuarios reciben contenido obsoleto al instante mientras la CDN obtiene la versión actualizada en segundo plano.

¿Cómo calculo el cache hit ratio ideal? Monitorea el hit ratio por tipo de contenido. Los assets estáticos deberían estar en 95%+. El contenido dinámico varía. Si el hit ratio baja, revisa el TTL, los patrones de acceso y la configuración de query strings.

¿Qué es una surrogate key y cuándo usarla? Una surrogate key es un identificador adicional para grupos de contenido. Permite invalidar múltiples URL con una sola key. Úsala cuando el contenido relacionado necesite actualizarse en conjunto (por ejemplo, todos los posts de una categoría).

¿Se puede almacenar caché privado en la CDN? No por defecto. Cache-Control: private indica que solo el navegador puede cachear. Las CDN respetan esta directiva. Para caché compartido con control de acceso, usa public con autenticación en el edge.

¿Cómo evito un purge accidental de toda la caché? Implementa protecciones: exige confirmación para purges amplios, limita la frecuencia de purge, usa surrogate keys para invalidación selectiva, monitorea y alerta sobre purges sospechosos.

¿Cuál es la diferencia entre PURGE y BAN? PURGE elimina el contenido de la caché de inmediato. BAN marca el contenido como inválido pero puede seguir sirviendo contenido obsoleto hasta revalidar. PURGE es más agresivo, BAN es más gradual.

¿Cómo manejo el caché para API autenticadas? Usa Cache-Control: private o no-store para datos específicos del usuario. Para datos que se pueden cachear por usuario, usa headers Vary: Authorization o claves de caché que incluyan el ID del usuario.

¿El caché CDN es lo mismo que el caché del navegador? No. El caché CDN se almacena en el servidor edge, sirviendo a múltiples usuarios. El caché del navegador es local en el dispositivo del usuario. Las CDN usan s-maxage para su caché, los navegadores usan max-age.

¿Cómo configuro el caché para Single Page Applications? HTML (index.html): no-cache o TTL corto (siempre revalida). JS/CSS versionados: TTL largo (1 año). API: TTL según criticidad. La SPA necesita revalidar el HTML para obtener nuevos chunks.

Cómo aplica esto en la práctica

Un caché CDN bien configurado reduce la latencia entre 60-90% y la carga del origen entre 70-95%. El costo de la invalidación (purges, webhooks) se compensa con el ahorro de ancho de banda y una mejor experiencia de usuario.

Configura TTL agresivos para contenido inmutable, manejadores de stale para resiliencia e invalidación selectiva para contenido cambiante. Monitorea el hit ratio y el TTFB de forma continua. Ajusta los TTL con base en patrones de acceso reales, no en suposiciones.

Cómo implementarlo con Azion

Azion brinda control completo de caché en el edge:

1. Edge Cache: configura TTL, manejadores de stale y reglas basadas en path
2. Edge Functions: implementa lógica de caché personalizada en JavaScript/Wasm
3. Cache API: programa invalidaciones vía GraphQL o REST API
4. Real-Time Metrics: monitorea hit ratio, TTFB y volumen por path

Configuración típica de Azion:

Rules Engine:
- Si: el path coincide con /static/*
  Entonces: Cache TTL = 31536000 (1 año)

- Si: el path coincide con /api/*
  Entonces: Cache TTL = 60, stale-while-revalidate = 3600

- Si: el path coincide con /page/*
  Entonces: Cache TTL = 300, stale-if-error = 86400

Aprende más en la documentación de Azion Serverless Applications.

Recursos relacionados

• Edge Computing vs CDN
• ¿Qué es JWT?
• Aplicaciones serverless
• MDN: HTTP Caching
• RFC 7234: HTTP Caching

Fuentes:

• RFC 7234. “Hypertext Transfer Protocol (HTTP/1.1): Caching.” IETF. 2014.
• CDN Planet. “Cache Hit Ratio Benchmarks.” 2024.
• HTTP Archive. “Web Almanac 2024: Caching.” 2024.