El problema fundamental que resuelve esta re-arquitectura es la gestión de la complejidad operativa y la falta de observabilidad en sistemas distribuidos heterogéneos. La arquitectura original de cdnjs, aunque funcional en términos de rendimiento de cara al usuario, se había vuelto un cuello de botella para la evolución y el mantenimiento debido a la dispersión de componentes en diferentes proveedores de nube y la ausencia de un estado unificado.
La necesidad de esta migración surge ahora porque la Plataforma de Desarrolladores de Cloudflare ha madurado lo suficiente como para ofrecer un conjunto cohesivo de servicios (Workers, Workflows, R2, KV, Queues, Containers, Durable Objects) que pueden reemplazar la infraestructura fragmentada. Esto permite consolidar el stack, mejorar la trazabilidad de los flujos de trabajo y simplificar la seguridad y el mantenimiento, al tiempo que se elevan los límites de la plataforma para satisfacer las demandas de un servicio a escala de hyperscaler.
Históricamente, la evolución de los CDNs ha pasado de servidores de origen estáticos a arquitecturas distribuidas con capas de caché complejas. La migración de cdnjs representa un paso más allá, integrando la lógica de procesamiento y publicación de contenido directamente en la red de borde, aprovechando la programabilidad de la red para una mayor agilidad y eficiencia operativa.
Arquitectura del Sistema
La nueva arquitectura de cdnjs se asienta completamente en la Plataforma de Desarrolladores de Cloudflare. R2 (compatible con S3 API) se establece como la única fuente de verdad para el contenido de los archivos, eliminando la duplicidad y los problemas de 'split-brain' del sistema anterior. KV se utiliza exclusivamente para metadatos (información de paquetes, listas de versiones, SRI hashes), aprovechando su diseño para altos volúmenes de lectura con escrituras infrecuentes. Workers Cache, una capa de caché en el borde, se sitúa delante del Worker para optimizar el rendimiento de las lecturas.
El pipeline de ingesta se construye sobre Cloudflare Workflows, que orquesta el proceso de actualización de paquetes. Un cron job activa periódicamente un Workflow principal (PackageUpdatesWorkflow) que verifica nuevas versiones en npm y GitHub. Por cada nueva versión, se lanzan Workflows secundarios (DownloadPackageWorkflow, ProcessingWorkflow, PublishingWorkflow) que descargan el tarball a R2, extraen, minifican y comprimen los archivos, y finalmente escriben los resultados a R2 y KV, actualizando también un índice de búsqueda (Algolia).
Para tareas intensivas en CPU como la compresión, Workflows se integra con Cloudflare Containers. Los archivos no comprimidos se escriben en un bucket de R2, se envía un trabajo a una Queue y el Workflow hiberna. Un servicio de compresión en Rust dentro de un Container procesa el archivo, escribe el resultado en otro bucket de R2, y una notificación de evento de R2 despierta el Workflow para continuar. Para coordinar la finalización de múltiples tareas de procesamiento de archivos para un solo paquete, se utiliza un Durable Object como contador distribuido, permitiendo que el Workflow padre espere a que todos los hijos terminen antes de proceder a la publicación. La resiliencia se mejora con una copia de recuperación ante desastres en DigitalOcean Spaces, a la que el Worker de servicio recurre si R2 no puede devolver un archivo.
Flujo de Ingesta y Publicación de Paquetes
- 1 Cron Job Activa PackageUpdatesWorkflow cada 10 minutos.
- 2 PackageUpdatesWorkflow Verifica nuevas versiones en npm y GitHub.
- 3 DownloadPackageWorkflow Descarga el tarball de la nueva versión a R2.
- 4 ProcessingWorkflow (por archivo) Escribe archivo no comprimido a R2, envía job a Queue, hiberna.
- 5 Container (Rust service) Recoge job de Queue, comprime archivo, escribe a R2.
- 6 R2 Event Notification Despierta ProcessingWorkflow al completar compresión.
- 7 Durable Object Contador para que el Workflow padre espere a todos los hijos.
- 8 PublishingWorkflow Escribe resultados finales a R2 y KV, actualiza Algolia.
| Capa | Tecnología | Justificación |
|---|---|---|
| storage | Cloudflare R2 | Almacenamiento de objetos como fuente única de verdad para el contenido de archivos, sin límites de tamaño y con API S3. vs Google Cloud Storage (GCS), GitHub repository |
| cache | Cloudflare Workers Cache | Capa de caché en el borde para optimizar las lecturas de archivos, reemplazando una capa interna previa. vs Capa de caché interna propietaria |
| storage | Cloudflare KV | Almacenamiento de clave-valor para metadatos (info de paquetes, versiones, SRI hashes), optimizado para altas lecturas. vs Google Cloud Storage (GCS) para metadatos |
| orchestration | Cloudflare Workflows | Motor de orquestación para el pipeline de ingesta y publicación, con ejecución duradera y tolerancia a fallos. vs GCP Cloud Functions (cadena de funciones) Límite de pasos elevado a 10,000 (configurable a 25,000). |
| compute | Cloudflare Workers | Servicio serverless para la lógica de servicio de archivos en el borde y la ejecución de Workflows. vs GCP Functions Límite de subrequests elevado a 10 millones en planes de pago. |
| compute | Cloudflare Containers | Ejecución de servicios intensivos en CPU, como la compresión de archivos, integrados con Workflows. vs VMs en GCP |
| messaging | Cloudflare Queues | Cola de mensajes para la comunicación asíncrona entre Workflows y Containers, y para paralelizar migraciones. vs GCP Pub/Sub, Eventos de GCS Garantía de entrega 'at-least-once'. |
| data-processing | Cloudflare Durable Objects | Coordinación de estado distribuido, usado como contador para sincronizar Workflows padre/hijo. vs Bases de datos distribuidas para contadores |
Trade-offs
Ganancias
- ▲ Observabilidad y trazabilidad
- ▲ Consistencia de datos (fuente única de verdad)
- ▲ Agilidad en el desarrollo y despliegue
- ▲ Seguridad (menos componentes a auditar)
- ▲ Simplificación de la arquitectura
Costes
- ▲ Complejidad inicial de la migración
- △ Necesidad de elevar límites de plataforma
Fundamentos Teóricos
La problemática de la consistencia de datos en sistemas distribuidos, especialmente cuando se manejan múltiples fuentes de verdad, es un tema central en la ciencia de la computación. El problema de 'split-brain' en la arquitectura anterior de cdnjs, donde los archivos residían en Workers KV y un repositorio de GitHub sin una autoridad clara, es un ejemplo clásico de los desafíos que aborda el teorema CAP y sus extensiones como PACELC. La elección de R2 como 'single source of truth' busca establecer una consistencia fuerte para el estado de los archivos, simplificando el modelo de programación y reduciendo la complejidad de la reconciliación.
La orquestación de flujos de trabajo duraderos y tolerantes a fallos, como los implementados con Cloudflare Workflows, se relaciona con conceptos de sistemas de flujo de trabajo transaccionales y compensatorios. La capacidad de reanudar un flujo de trabajo desde el último paso exitoso, incluso después de fallos transitorios, se alinea con los principios de la ejecución de transacciones de larga duración y la idempotencia. Aunque no se menciona explícitamente, la gestión de la concurrencia y el estado distribuido con Durable Objects para coordinar tareas paralelas evoca patrones de diseño para la consistencia eventual y la coordinación de procesos en entornos distribuidos, como los discutidos en papers sobre sistemas de coordinación basados en objetos o actores.