Una vista panorámica de la plataforma Workers
Cloudflare Workers es un FaaS basado en V8 Isolate que, a abril de 2026, despliega el mismo código de forma inmediata en más de 330 ciudades PoP. El cold start es prácticamente cero (menos de 5 ms para la mayoría de las solicitudes), pero a diferencia de un contenedor como AWS Lambda, las restricciones de usar un Isolate hacen que los módulos nativos de Node.js y el I/O bloqueante de larga duración no encajen por naturaleza. Con nodejs_compat_v2, lanzado en la segunda mitad de 2025, la compatibilidad de fs/crypto/stream mejoró significativamente, pero aún así, sin entender el "estilo Isolate", se chocará contra el límite de sub-solicitudes (1000) o el límite de tiempo de CPU (5 minutos en el plan de pago).
Donde Workers realmente genera valor es en el momento en que combina lógica stateful con Durable Objects. Un Durable Object (en adelante DO) es un "actor con ID globalmente único, single-threaded y de consistencia fuerte", y las solicitudes siempre se serializan para el mismo DO. Este modelo está diseñado como "un sustituto de mutex en el edge", lo que permite completar localmente sin RTT intermedio lo que anteriormente se implementaba con Redis o advisory lock de Postgres: "limitación de velocidad por usuario", "señalización por sala de reuniones", "asignación de inventario por ID de transacción".
El modelo transaccional de Durable Objects
El almacén persistente de los DO proporciona internamente una API de almacenamiento basada en SQLite. Desde que los DO respaldados por SQLite se abrieron a todos los planes en 2025, es posible almacenar hasta 10 GB de datos relacionales por DO, y ejecutar de forma atómica múltiples put/delete dentro del callback transaction(). Lo importante es que los DO contienen una "puerta de entrada" y una "puerta de salida". La puerta de entrada bloquea nuevas solicitudes mientras espera escrituras de almacenamiento durante el procesamiento de solicitudes, y la puerta de salida pospone la respuesta de fetch hasta que las escrituras de almacenamiento se persisten. Gracias a estas dos puertas, el código de la aplicación puede escribir async/await libremente sin que la consistencia se rompa.
```typescript export class InventoryDO { state: DurableObjectState; constructor(state: DurableObjectState) { this.state = state; } async fetch(req: Request) { const { sku, qty } = await req.json<{ sku: string; qty: number }>(); return await this.state.storage.transaction(async (tx) => { const current = (await tx.get<number>(sku)) ?? 0; if (current < qty) return new Response("oos", { status: 409 }); await tx.put(sku, current - qty); return new Response(JSON.stringify({ remain: current - qty })); }); } } ```
El error más común al usar los DO de manera similar a los actores es el diseño de "procesar todos los tenants en 1 DO". Si un DO se convierte en un hotspot, el PoP queda fijo, forzando alta latencia a los usuarios geográficamente distantes. La respuesta correcta es usar idFromName() para concatenar "ID de tenant + ID de recurso" para el sharding, de modo que las escrituras tengan localidad geográfica. Las lecturas se pueden devolver en O(1) desde un DO réplica (GA en 2025).
Workers KV, Hyperdrive y D1: cómo diferenciarlos
Las tres capas de datos tienen propósitos claramente diferenciados. Workers KV es un almacén optimizado para lectura con consistencia eventual, adecuado para configuraciones y metadatos que pueden tolerar propagación dentro de 60 segundos. La latencia de propagación de PUT va de segundos a 60 segundos, y las lecturas se devuelven en 1 ms desde la caché local del PoP. Hyperdrive es un pool de conexiones a Postgres/MySQL externos que reutiliza conexiones TCP al origen mientras almacena en caché los resultados de consultas en el PoP. Es el primer paso más realista para organizaciones con activos de RDB existentes que migran al edge. D1 es la RDB basada en SQLite propia de Cloudflare; las réplicas de lectura se publicaron de manera general en 2025, permitiendo una topología estilo PostgreSQL donde las escrituras van al primario y las lecturas a la réplica más cercana.
El criterio de selección se descompone en "frecuencia de escritura" y "requisitos de consistencia". Si hay más de 1000 escrituras por segundo y es posible aislar por tenant, usa DO; si hay pocas escrituras globales + lecturas distribuidas geográficamente, usa D1; si ya tienes una base de datos externa, usa Hyperdrive; si hay distribución de configuración basada en TTL, usa KV. R2 (almacén de objetos compatible con S3) es ortogonal a estos y se usa para distribución de video, backup y data lakes aprovechando la característica de egreso gratuito.
Workers AI y enrutamiento de inferencia
Desde que Workers AI estuvo disponible de manera general en 2024, es posible invocar principales modelos OSS como Llama 3.3 70B, Mistral Large 2, GPT-OSS-120B, Qwen 3 con pago por uso. A 2026, es posible enrutar OpenAI/Anthropic/Google a través de una misma API (AI Gateway) con BYOK, y el almacenamiento en caché de respuestas, reintentos y limitación de velocidad se pueden gestionar de forma unificada en el lado de Workers. Los logs de AI Gateway fluyen hacia Analytics Engine, lo que permite consultar el costo de tokens por prompt con SQL.
La práctica estándar para la optimización de latencia es el híbrido "inferencia pequeña localmente con Workers AI, inferencia compleja con LLM externo". Por ejemplo, hemos confirmado múltiples casos en nuestra empresa donde se reduce el costo en un 70% mediante enrutamiento en dos etapas: gestionar la detección de bots, clasificación NSFW y detección multilingüe con Llama Guard/Llama-3 8B de Workers AI, y solo escalar a Claude o GPT cuando el resultado es "incierto".
Optimización del hot path con bindings Rust + WASM
TypeScript en 5 ms, Rust + WASM en 0,8 ms. Esta diferencia importa con 100.000 solicitudes por segundo, directamente relacionada con el presupuesto de tiempo de CPU. workers-rs (Rust crate) puede compilarse al runtime de Workers con el macro `#[event(fetch)]`, y puede acceder a las APIs de Workers (fetch/crypto/R2) a través de wasm-bindgen. El efecto de reducción de costos es grande cuando se reescribe en Rust el parseo de JSON pesado en API gateways, verificación de HMAC, verificación de JWT y redimensionamiento de imágenes.
```rust use worker::*; #[event(fetch)] async fn main(req: Request, env: Env, _ctx: Context) -> Result<Response> { let body: serde_json::Value = req.json().await?; let signature = req.headers().get("x-signature")?.unwrap_or_default(); if !verify_hmac(&body, &signature, &env.secret("HMAC_KEY")?.to_string()) { return Response::error("invalid signature", 401); } Response::ok("ok") } ```
Como punto de atención, el tamaño del módulo WASM debe mantenerse por debajo de 10 MB, y la combinación de wasm-opt -Oz y wee_alloc puede reducir el tamaño efectivo a la mitad. El costo de inicio es prácticamente ignorable gracias a la reutilización del Isolate, pero la primera compilación tarda 20-50 ms, por lo que en PoPs con tráfico extremadamente bajo puede producirse la inversión donde TypeScript es más rápido. Los benchmarks deben tomarse en PoPs de producción.
Patrones de construcción de máquinas de estado globales
La combinación de WebSocket Hibernation + Durable Objects se ha convertido en el estándar para edición colaborativa en tiempo real, señalización de transmisión en vivo y orquestación de dispositivos IoT. Gracias a la API de Hibernation, las conexiones WebSocket pueden permanecer abiertas mientras se libera la memoria, y la facturación de los DO es solo por "tiempo activo". La estructura de costos donde mantener 1 millón de conexiones cuesta solo unos pocos miles de dólares al mes está generando la motivación de recrear servicios tipo Ably o Pusher de forma propia.
El punto clave en el diseño es tratar el DO como "un solo nodo de la máquina de estado". Las transiciones de estado actualizan atómicamente la versión de estado con CAS dentro de storage.transaction, y los eventos externos se disparan a través de Queues. Las transacciones compensatorias en caso de fallo se pueden ejecutar de forma diferida con la API alarm(). Con esto se puede construir el patrón saga que "comienza en el edge y termina en el edge" con baja latencia. La arquitectura que no regresa al origen es el principal campo de batalla del diseño de sistemas distribuidos en 2026.