El problema: el tráfico de medios aplasta el origin
Cuando las fotos de producto, videos hero, PDFs, y subidas de usuario viven en el mismo servidor que renderiza tus páginas, cada solicitud de imagen compite con el trabajo real de la aplicación por CPU, I/O de disco, y ancho de banda. Una sola página popular con treinta imágenes multiplica el tráfico por treinta contra un solo origin, y un pico de tráfico o una descarga de video grande pueden dejar a la app sin los recursos que necesita para responder en absoluto. El storage en un servidor de app también es difícil de escalar: eventualmente te quedas sin disco, y los backups de un filesystem gordo se vuelven lentos y frágiles. Separar los bytes de la lógica es la primera corrección estructural, y es lo que este escenario entrega.
Cómo lo resuelve cdn.com.tr: buckets más caché edge
Almacenas cada asset en un bucket de Object Storage compatible con S3, lo cual te da capacidad efectivamente elástica y un endpoint con el que tus aplicaciones hablan usando herramientas S3 estándar. Delante de ese bucket colocas el CDN de cdn.com.tr, así que la entrega real a los navegadores ocurre desde ubicaciones edge, no desde el bucket y nunca desde tu servidor de app. La primera solicitud de un archivo llena el caché edge; cada solicitud subsecuente de ese archivo se sirve desde el edge sin tocar Object Storage otra vez. El resultado es que tu origin maneja casi nada del tráfico de bytes, tu capa de storage escala independientemente del computo, y los usuarios reciben assets desde un nodo edge cercano en lugar de un solo servidor distante.
Access keys, assets públicos, y archivos privados
Cada bucket se controla con pares de access key y secret que creas, rotas, y revocas desde el panel. Para medios públicos como imágenes de catálogo los entregas a través del dominio del CDN y mantienes el endpoint crudo del bucket fuera de tu markup. Para material privado como descargas pagadas o backups internos mantienes los objetos no públicos y entregas URLs firmadas de corta duración generadas con el access key, así que un enlace expira en lugar de vivir para siempre. Como cada integración obtiene su propia clave, un uploader comprometido o un contratista que se va es una revocación de un clic en lugar de un reseteo de contraseñas a nivel de plataforma.
Cache-control y purge sin envenenarte el caché a ti mismo
El caché es tan bueno como los headers que defines en tus objetos. Dale a los assets versionados de larga duración un Cache-Control con immutable de futuro lejano, y dale a las cosas que genuinamente cambian con frecuencia un TTL más corto. El patrón más limpio es nombres de archivo con hash de contenido: cuando una imagen cambia, su URL cambia, así que el edge sirve naturalmente el archivo nuevo y nunca peleas con caché desactualizado. Cuando debes sobrescribir un archivo en la misma URL — un cambio de logo, un PDF corregido — un purge dirigido desde el panel o cdnctl descarta ese objeto de cada ubicación edge para que la siguiente solicitud lo vuelva a extraer del bucket. Esto mantiene las invalidaciones raras, precisas, y seguras.
Escalar de unas pocas imágenes a una biblioteca de medios completa
La misma configuración que sirve un puñado de logos escala a un catálogo de cientos de miles de fotos de producto, una biblioteca de video on-demand, o un archivo rotativo de backups nocturnos, porque Object Storage crece sin que tu aprovisiones discos y el edge absorbe el tráfico de lectura. Los sitios con mucho contenido multimedia ven las ganancias más marcadas: las páginas se vuelven más livianas y rápidas a medida que las imágenes fluyen desde edges cercanos, y el ancho de banda del origin — a menudo el recurso más costoso y más frágil — cae drásticamente. Los backups también obtienen un hogar limpio, aislados en su propio bucket privado con su propia access key, lejos del camino de entrega público.
Dónde encaja con el resto de la plataforma
Este escenario está deliberadamente enfocado en storage y entrega, pero compone con todo lo demás en la cuenta. Una aplicación WordPress o PHP puede descargar su directorio de subidas a un bucket y seguir sirviendo el sitio a través del mismo edge. Una container app puede conectar el bucket como variables de entorno y leer o escribir objetos directamente. El DNS y Auto SSL manejan el dominio de entrega, y el purge, los logs, y el status te dan la visibilidad operativa para confirmar que los assets fluyen desde caché y no fallan silenciosamente hacia el origin en cada solicitud.
Cómo configurarlo, paso a paso
Crea un bucket
En el panel abre Object Storage y crea un bucket para tus medios (por ejemplo media-prod). Obtienes un endpoint compatible con S3, una region, y un nombre de bucket. Mantén buckets separados para assets públicos y backups privados para que sus políticas de acceso nunca se superpongan.
Genera un access key con alcance limitado
Crea un par de access key / secret para el bucket y pégalo en tu uploader, CMS, o SDK de S3. Usa una clave por aplicación para que puedas rotar o revocar una sola integración sin romper las demás. Las claves se pueden rotar desde el panel en cualquier momento si una se filtra.
Sube con los headers correctos
Empuja assets con tu cliente S3 existente, aws-cli, o plugin, definiendo Content-Type y un Cache-Control largo (por ejemplo max-age=31536000, immutable) en archivos que nunca cambian. Usa nombres de archivo con hash de contenido como logo.a1b2c3.png para que una versión nueva sea una URL nueva y nunca necesite invalidación.
Pon el CDN delante
Conecta un dominio de entrega (por ejemplo cdn.example.com) al CDN y apunta su origin al endpoint del bucket. Las solicitudes ahora golpean el edge primero, se cachean en todas las ubicaciones, y solo hacen miss hacia Object Storage en la primera solicitud por asset. Auto SSL emite el certificado para el dominio de entrega automáticamente.
Verifica el comportamiento del caché
Carga un asset dos veces y revisa los headers de respuesta en busca de un HIT en la segunda solicitud. Confirma que tu Cache-Control se está respetando y que los tipos MIME de imagen/video son correctos para que los navegadores y el edge los cacheen apropiadamente.
Conecta el purge
Cuando sobrescribas un archivo en la misma URL, emite un purge desde el panel o vía cdnctl para que el edge descarte la copia desactualizada. Para assets que versionas por nombre de archivo rara vez necesitas esto, que es exactamente por qué se recomiendan nombres con hash de contenido para medios de alta rotación.
Escenarios de ejemplo
Miles de fotos de producto viven en un bucket y fluyen desde el edge, así que las páginas de listado y detalle se mantienen rápidas durante campañas sin cargar el servidor de app de la tienda.
El video on-demand y los archivos de instalador se almacenan una vez y se entregan desde caché, manteniendo el ancho de banda del origin plano incluso cuando un archivo se vuelve viral de repente.
Los backups nocturnos de base de datos y archivos van a un bucket privado con una access key dedicada, mantenidos completamente fuera del camino de entrega público y rotables bajo demanda.
Preguntas frecuentes
El storage es realmente compatible con S3 con mis herramientas existentes?
Si. Los buckets exponen un endpoint compatible con S3, así que aws-cli, s3cmd, rclone, y los AWS SDKs funcionan apuntándolos al endpoint con tu access key y secret. La mayoría de los plugins de subida de CMS y frameworks que soportan S3 funcionan de la misma forma.
Los usuarios golpean el bucket directamente, o el CDN?
Para entrega publica apuntas un dominio del CDN al endpoint del bucket y publicas ese dominio en tu markup, así los usuarios siempre golpean el caché edge. El endpoint crudo del bucket se mantiene detrás del CDN y no es lo que tus páginas referencian.
Cómo sirvo archivos privados sin hacer el bucket público?
Mantén los objetos privados y genera URLs firmadas de corta duración con tu access key. El enlace otorga acceso por tiempo limitado y luego expira, que es el patrón correcto para descargas pagadas, facturas, o cualquier cosa que no deba ser pública de forma permanente.
Si reemplazo una imagen con el mismo nombre de archivo, por qué sigue mostrando la anterior?
Porque el edge cacheo la versión anterior bajo esa URL. Emite un purge para ese objeto desde el panel o cdnctl, o adopta nombres de archivo con hash de contenido para que cada versión nueva tenga una URL nueva y nunca necesite purge.
Qué Cache-Control debería definir en los medios?
Los assets versionados de larga duración deberían usar un max-age de futuro lejano con immutable; los archivos que cambian frecuentemente deberían usar un TTL más corto. Definir el header en el momento de la subida es lo que le permite al edge retener el archivo en lugar de volver a extraerlo del bucket.
Puedo revocar el acceso si una clave se filtra?
Si. Las access keys se rotan y revocan desde el panel por integración. Como emites una clave por aplicación, revocar una clave filtrada afecta solo a esa integración en lugar de a todos los servicios que leen el bucket.