ADR 002: Cloudflare Workers como plataforma edge

Contexto

Necesitamos una plataforma backend para API gateway, BFF workers, servicio de assets estaticos, gestión de configuración de versiones y funcionalidades WebSocket en tiempo real. La plataforma debe soportar computacion edge distribuida globalmente con minima carga operativa.

Decisión

Usar Cloudflare Workers con el ecosistema completo: R2 (almacenamiento), KV (clave-valor), D1 (SQL), Durable Objects (coordinación con estado) y service bindings (RPC entre Workers). Usar Wrangler v4 para desarrollo local y despliegue (Wrangler v3 llego a EOL en Q1 2026). Configurar compatibility_date = "2026-02-25" en todos los archivos de configuración de wrangler.

Consecuencias

Positivas

• 0ms de cold start (V8 isolates, no contenedores)
• Despliegue global en mas de 300 data centers
• Service bindings: comunicación entre Workers con latencia y coste cero
• Durable Objects con Hibernatable WebSockets para tiempo real eficiente en coste; soporta mensajes WebSocket de hasta 32 MiB
• R2 para almacenamiento de objetos compatible con S3 (bundles de MFE) sin costes de egress
• KV para lecturas de configuración distribuidas globalmente (cacheTtl minimo de 30s; soporta consistencia read-your-own-writes (RYOW) para escrituras seguidas de lecturas en el mismo nodo)
• D1 para SQL (audit trail, historial de versiones) sin gestión de servidores -- GA desde abril 2024, limite de almacenamiento de 1TB por cuenta
• El plan de pago de $5/mes cubre 10M de peticiones
• CLI Wrangler v4 para desarrollo local y despliegue
• El tiempo de CPU es configurable hasta 5 minutos via cpu_ms en wrangler.toml (por defecto 30ms en Workers Paid)

Negativas

• El runtime de Workers NO es Node.js (superficie de API limitada, sin fs, sin modulos nativos)
• Limite de 128MB de memoria por Worker
• Vendor lock-in con el ecosistema de Cloudflare
• Los Durable Objects tienen un limite de ~1000 req/sec por objeto
• KV es eventualmente consistente (~250ms de latencia global p99; la cifra de <5ms frecuentemente citada aplica solo a cache hits internos de KVSP, no a la propagación global)

Alternativas consideradas

• AWS Lambda@Edge / CloudFront Functions: Ecosistema mas maduro pero con cold starts (100-500ms), mayor coste, IAM complejo, sin equivalente a Durable Objects ni service bindings.
• Vercel Edge Functions: Buena DX pero limitada a la plataforma Vercel, sin equivalente a Durable Objects, R2 o D1. Menor control sobre la infraestructura.
• Servidores tradicionales (Node.js en ECS/GKE): API completa de Node.js pero requiere gestiónar servidores, escalado, balanceo de carga. Mayor carga operativa, mayor coste a escala.
• Deno Deploy: Buena plataforma edge basada en V8 pero ecosistema mas reducido, primitivas de almacenamiento menos maduras, sin equivalente a Durable Objects.

Documentación Relacionada

• Infraestructura Cloudflare — Guía detallada de servicios de plataforma y bindings
• Comunicación en Tiempo Real — Durable Objects para canales WebSocket
• Visión General de Arquitectura — Contexto de arquitectura del sistema