Diseñar dentro de los límites

Todo lo anterior de este nivel describía muros: tiempo de CPU, memoria, subrequests, tamaño. La tentación es tratarlos como enemigos y buscar cómo esquivarlos. Pero la lectura madura es la contraria: cada límite es una señal que te dice que ese trabajo, tal como lo planteas, no pertenece a un Worker de petición. La plataforma no te pide que hagas caber un elefante en una caja pequeña, sino que reconozcas cuándo el elefante necesita otra pieza —una cola, un flujo durable, un contenedor— y dejes al Worker hacer lo que hace de maravilla: recibir la petición y decidir a quién se la pasa.

Señales de que el trabajo no cabe

Antes de elegir una herramienta, aprende a leer los síntomas. Cada uno apunta a una carencia distinta del modelo de petición, y confundirlos lleva a la solución equivocada.

La respuesta a las tres primeras señales vive dentro del ecosistema de Workers; la cuarta te saca del isolate por completo. El hilo conductor es siempre el mismo: sacar el trabajo pesado de la ruta de la petición para que el usuario reciba una respuesta rápida y el trabajo ocurra donde tiene sitio.

Descargar con Queues, orquestar con Workflows

Queues resuelve la descarga. Tu Worker actúa de productor: recibe la petición, valida, mete un mensaje en la cola y responde de inmediato con un 202. El trabajo de verdad lo hace un consumidor, un Worker aparte que procesa los mensajes en segundo plano, por lotes, con reintentos, y con un presupuesto de CPU mucho mayor —hasta quince minutos por invocación—.

export default {
  async fetch(request, env): Promise<Response> {
    const trabajo = await request.json();
    // acepta rapido y encola: el usuario no espera al trabajo pesado
    await env.MI_COLA.send(trabajo);
    return new Response("aceptado", { status: 202 });
  },
};

Esa indirección compra tres cosas a la vez: desacopla la latencia del usuario del coste del trabajo, absorbe los picos de carga en un buffer, y da reintentos gratis cuando el procesamiento falla. Es el patrón para todo lo que puede ocurrir después: enviar correos, generar miniaturas, propagar cambios.

Workflows resuelve la orquestación. Cuando el trabajo no es un mensaje suelto sino una secuencia de pasos que debe sobrevivir a fallos, un Workflow describe esos pasos con step.do(). Cada paso que termina queda grabado para siempre y no se repite aunque el flujo se reinicie; los que fallan se reintentan con backoff; el estado sobrevive a caídas de infraestructura; y un flujo puede dormir esperando un evento durante hasta un año sin consumir recursos.

Salir del isolate con Containers

Hay trabajo que ninguna cola ni flujo arregla, porque el problema no es el tiempo ni la durabilidad sino la naturaleza del cómputo: necesitas ffmpeg, un runtime que no compila a WebAssembly, un sistema de ficheros completo o varios núcleos de CPU en paralelo. Para eso están los Containers: ejecutan una imagen de contenedor —cualquier lenguaje, cualquier runtime— dentro de una VM Linux, controlada desde tu Worker.

import { Container, getContainer } from "@cloudflare/containers";

export class Render extends Container {
  defaultPort = 8080;
  sleepAfter = "10m"; // duerme el contenedor tras 10 min sin trafico
}

export default {
  async fetch(request, env) {
    // el Worker enruta a un contenedor que corre el binario pesado
    return getContainer(env.RENDER, "sesion-1").fetch(request);
  },
};

El detalle revelador es que la clase Container extiende a un Durable Object: el objeto gestiona el enrutado, el estado y el ciclo de vida, mientras el proceso pesado corre dentro de la VM. No escribes operadores de Kubernetes ni encadenas llamadas de API: describes el contenedor en el manifiesto y lo invocas como una pieza más. Eso sí, un contenedor no arranca en cero como un isolate: tarda minutos en aprovisionarse y solo está disponible en el plan de pago. Es la herramienta de último recurso, no la primera.

flowchart TB
REQ[Peticion entrante] --> W[Worker recepcionista rapido]
W -- responde ya --> USER[Usuario]
W -- encola trabajo diferido --> Q[Queues consumidor en segundo plano]
W -- inicia proceso de varios pasos --> WF[Workflows pasos durables con reintentos]
W -- delega trabajo nativo o pesado --> C[Containers imagen en una VM linux]
style W fill:#89b4fa,color:#11111b
style Q fill:#a6e3a1,color:#11111b
style WF fill:#cba6f7,color:#11111b
style C fill:#fab387,color:#11111b