Los Workers de Cloudflare se modularizan para escalar SaaS multi‑tenant sin cuellos de botella
Una arquitectura de gateway + workers especializados elimina la dependencia de un único script y reduce el blast radius en despliegues de cientos de miles de inquilinos.
En una plataforma de edge que sirve a cientos de miles de cuentas SaaS, un solo Cloudflare Worker que controla todas las funcionalidades se convierte en un cuello de botella de despliegue y un punto de falla crítico. El autor propone dividir ese monolito en un gateway y varios workers de función única, conectados mediante service bindings que actúan como llamadas locales sin coste de red.
Problemas del monolito en el edge
Con un único worker, cualquier cambio obliga a redeplegar todo el script, alineando el ritmo de todas las squads y haciendo que una corrección menor se quede a la espera de experimentos en curso. Además, un error en cualquier módulo (por ejemplo, una expresión regular errónea) afecta a todas las funcionalidades y a todos los inquilinos simultáneamente, lo que multiplica el impacto de una incidencia.
Los límites de CPU y tamaño de script de los Workers agravan la situación: cada dependencia adicional infla el bundle compartido y aumenta el tiempo de parsing, aun cuando la petición no requiera ese código. La falta de aislamiento también genera conflictos de propiedad y dificulta la iteración rápida, sobre todo en pipelines de imágenes donde el formato (AVIF, WebP, JPEG) y el dimensionado dependen de la configuración por inquilino.
Arquitectura modular propuesta
La solución consiste en un worker del tipo gateway que solo orquesta la cadena de ejecución y gestiona preocupaciones transversales (preparación de la solicitud, cabeceras, observabilidad). Cada funcionalidad –optimización de imágenes, failover, reescritura de cabeceras, búsquedas de configuración por inquilino– se implementa en un worker dedicado, con su propio bundle, pruebas unitarias y ciclo de despliegue independiente. La comunicación entre el gateway y los workers se realiza mediante service bindings, que Cloudflare ejecuta dentro del mismo aislado, evitando DNS, TLS o latencias de red adicionales.
Esta separación mantiene la latencia mínima que exige el edge, ya que la llamada interna tiene el coste de una simple función, y permite a los equipos trabajar en paralelo sin bloquearse mutuamente. Además, los rollback pueden hacerse a nivel de feature worker, limitando el blast radius a la funcionalidad afectada.
Comparación con Akamai
El artículo también muestra que, aunque Akamai y Cloudflare ofrecen capacidades similares, sus modelos de ejecución difieren: portar una funcionalidad de un proveedor a otro implica una re‑arquitectura completa, no solo un cambio de configuración. Por tanto, la modularidad propuesta no solo mejora la operatividad interna, sino que también facilita la gestión de entornos multi‑CDN.
La adopción de esta arquitectura modular permite escalar a nivel SaaS sin sacrificar la velocidad del edge, mientras se preserva una disciplina de pruebas y despliegues propia de aplicaciones tradicionales.
Esta estrategia ya está en producción en la plataforma del autor, que maneja más de 200 000 inquilinos y ha visto una reducción notable en tiempos de despliegue y en incidentes de ámbito global.
