La mayoría de CDNs son servicios independientes. Te registras con un proveedor externo, apuntas tu DNS a su red y esperas que funcione bien con el resto de tu infraestructura. Tu servidor origen está en un sitio, la CDN está en otro completamente distinto, y el tráfico entre ambos va por internet público.

La CDN de CubePath funciona de otra manera. Está construida sobre la misma red global que alimenta todo lo demás en la plataforma. Los mismos PoPs en Miami, Houston, Virginia y España. El mismo BGP multihoming y enrutamiento Anycast. El mismo backbone privado con MTU 9000 conectándolo todo. La CDN no es un servicio externo atornillado. Es una extensión nativa de la infraestructura donde los servidores ya están corriendo.

Este post explica cómo funciona la CDN de CubePath, qué la hace diferente y por qué importa para equipos que se toman en serio el rendimiento.

Cómo Funciona: Anycast, Caché en el Edge y el Backbone Privado

Cuando un usuario solicita contenido de un dominio detrás de la CDN de CubePath, esto es lo que ocurre:

BGP lo enruta al PoP más cercano. Gracias a Anycast, la petición del usuario aterriza automáticamente en el Punto de Presencia más cercano de CubePath. Un usuario en Ciudad de México llega a Houston. Un usuario en Barcelona llega a España. Un usuario en Nueva York llega a Virginia. Sin trucos de GeoDNS, sin lógica en el cliente. La red se encarga.

Si el contenido está cacheado, se sirve inmediatamente. Los assets estáticos como imágenes, CSS, JavaScript, fuentes y vídeos se cachean en el edge. Cuando llega una petición de contenido que ya está en la caché del PoP, se sirve directamente desde esa ubicación. El servidor origen no se contacta. La respuesta es rápida porque los datos han viajado una distancia corta.

Si no está cacheado, la petición al origen va por el backbone privado. Aquí es donde la CDN de CubePath se diferencia de las CDNs externas. Cuando hay un cache miss y el PoP necesita obtener contenido del origen, esa petición no va por internet público. Va por el backbone privado de CubePath con MTU 9000. La misma red interna rápida, de baja latencia y alto throughput que conecta toda la infraestructura de CubePath. Las cargas de caché son más rápidas, y el origen nunca se expone a internet público para estas peticiones.

TLS termina en el edge. El handshake TLS, que requiere múltiples ida y vuelta y es muy sensible a la latencia, ocurre en el PoP más cercano. Como el PoP está geográficamente cerca del usuario, esas ida y vuelta son cortas y la conexión se establece rápido. Esto reduce directamente el time-to-first-byte para tráfico HTTPS.

Para el cliente, la configuración es directa. Apuntar el dominio a la CDN de CubePath, y el tráfico empieza a fluir por la red de edge. Sin configuración compleja, sin cuentas separadas, sin hacer malabares entre proveedores.

Caché Inteligente con Reglas Personalizables

De serie, la CDN de CubePath cachea contenido estático automáticamente. Imágenes, hojas de estilo, bundles de JavaScript, fuentes, vídeos, cualquier cosa con cabeceras de caché estándar se almacena en el edge y se sirve a los usuarios siguientes sin tocar el origen.

Pero no todas las aplicaciones son iguales, y el comportamiento por defecto no siempre es suficiente. La CDN de CubePath da control total sobre la lógica de caché:

Caché por path. Servir todo lo que esté bajo /static/ desde el edge con un TTL largo, pero ir siempre al origen para los endpoints /api/. Definir diferentes estrategias de caché para diferentes partes de la aplicación basándose en patrones de URL.

Caché por headers y query strings. ¿Necesitas cachear diferentes versiones de una página según la cabecera Accept-Language? ¿O variar la caché por parámetros de query específicos? Las reglas personalizadas lo manejan sin workarounds.

TTLs configurables. Establecer cuánto tiempo permanece el contenido en la caché del edge antes de revalidarse con el origen. TTLs cortos para contenido que cambia frecuentemente, TTLs largos para assets que rara vez cambian. Ajustar el equilibrio entre frescura y rendimiento.

Purga de caché instantánea. Cuando se publica contenido nuevo, purgar la caché inmediatamente desde el panel de control o vía la API. Sin esperar a que los TTLs expiren, sin contenido obsoleto sirviéndose a los usuarios. Desplegar la actualización, purgar, y la nueva versión está disponible globalmente en segundos.

Cache bypass para contenido dinámico. Respuestas de API, páginas autenticadas, datos en tiempo real. Marcar paths específicos o patrones de petición como no cacheables para que siempre vayan al origen. La CDN se encarga del enrutamiento y la terminación TLS, y el origen se encarga de la respuesta.

Protección DDoS Integrada

Cuando el tráfico pasa por la CDN de CubePath, llega a la red de PoPs antes de alcanzar el servidor origen. Esta arquitectura proporciona protección DDoS como efecto natural de cómo funciona la CDN.

El tráfico se distribuye entre PoPs. Como Anycast enruta a los usuarios al PoP más cercano, el tráfico de ataque se reparte entre múltiples ubicaciones automáticamente. Un ataque volumétrico que saturaría un solo servidor se absorbe en toda la red de PoPs. Cada ubicación gestiona una fracción del volumen.

El origen queda protegido. Con la CDN delante, la IP real del servidor origen nunca se expone a los usuarios finales. El tráfico de ataque golpea el edge, donde puede ser identificado y filtrado antes de que alcance la infraestructura que ejecuta la aplicación real.

No es un servicio separado. No hay un producto adicional de protección DDoS que comprar o configurar. La protección viene de la propia arquitectura de la CDN. El tráfico fluye por la red distribuida de PoPs, y el origen se sienta detrás. La misma infraestructura que entrega contenido rápido también absorbe tráfico malicioso.

Para Quién Es la CDN de CubePath

Plataformas e-commerce sirviendo clientes en América y Europa. Las imágenes de productos, páginas de categorías y assets estáticos se cargan desde el PoP más cercano. Cargas de página más rápidas significan mejores tasas de conversión. Durante picos de tráfico como rebajas, la caché del edge absorbe la carga en vez de machacar el origen.

Aplicaciones SaaS con usuarios globales. El dashboard de la aplicación, el sitio de marketing, la documentación y los assets estáticos se benefician de la caché en el edge. Los usuarios en diferentes regiones obtienen rendimiento consistente sin necesidad de desplegar la aplicación en múltiples ubicaciones.

Plataformas de media y contenido. Imágenes, vídeo, descargas, podcasts. Los archivos grandes son los que más se benefician de la entrega desde el edge porque son los más caros de servir desde un solo origen. La CDN de CubePath los cachea en cada PoP y los sirve desde la ubicación más cercana al espectador.

Cómo Se Compara con Usar una CDN Externa

La pregunta obvia: ¿por qué no usar simplemente Cloudflare, Fastly o BunnyCDN?

Son buenos productos. Pero usar una CDN externa encima de la infraestructura de CubePath introduce compromisos que desaparecen con una CDN nativa:

Las peticiones al origen se quedan en la red privada. Cuando una CDN externa tiene un cache miss, busca en el origen por internet público. Cuando la CDN de CubePath tiene un cache miss, busca por el backbone privado con MTU 9000. Cargas de caché más rápidas, menos carga en el origen, y el origen nunca se expone públicamente para estas peticiones.

Un proveedor, una plataforma. Servidores, Kubernetes, DNS, Load Balancers y CDN gestionados desde el mismo panel y API. Sin cuentas separadas, sin facturación separada, sin cambiar de contexto entre proveedores. Cuando algo necesita depuración, todo está en un solo sitio.

Sin dependencia externa para un camino crítico. La CDN es a menudo lo primero que los usuarios tocan. Hacer que eso dependa de un servicio de terceros significa añadir un punto de fallo fuera de tu control. Con la CDN de CubePath, la capa de entrega de contenido corre en la misma infraestructura y red que todo lo demás. Las mismas garantías de uptime, el mismo equipo de soporte, la misma responsabilidad.

Configuración que encaja con la infraestructura. La CDN de CubePath conoce el resto de la plataforma de CubePath. Las reglas de caché, la configuración del origen y los certificados SSL se integran de forma nativa en vez de requerir configuración manual entre dos sistemas separados.

Esto no significa que las CDNs externas estén mal para todos los casos. Para equipos ejecutando infraestructura en múltiples proveedores cloud, una CDN independiente tiene sentido. Pero para equipos que ya están en CubePath, la CDN nativa elimina una capa de complejidad y entrega mejor rendimiento entre el edge y el origen.

La CDN Es una Extensión Natural de la Red

CubePath no construyó una CDN desde cero de forma aislada. La CDN es lo que ocurre cuando una red global con Anycast, BGP multihoming, EVPN y MTU 9000 recibe una capa de caché encima.

Los PoPs ya estaban ahí. El enrutamiento Anycast ya estaba ahí. El backbone privado ya estaba ahí. La resiliencia DDoS por tráfico distribuido ya estaba ahí. Añadir caché de contenido y reglas de entrega a esa base fue el siguiente paso natural.

Para equipos que ya tienen servidores en CubePath, activar la CDN significa añadir una capa de caché y entrega encima de una infraestructura que ya está optimizada para el rendimiento. La red es rápida, la petición al origen es rápida, y la caché está cerca de los usuarios.

Eso es lo que una CDN debería ser. No un producto separado de un proveedor separado. Una extensión de la infraestructura que ya está haciendo el trabajo.