Memoria y subrequests

El límite de CPU habla del tiempo; estos dos hablan del espacio y de la conversación. Cuánta memoria puede reservar tu Worker mientras trabaja, y cuántas llamadas salientes puede lanzar por cada petición que atiende. Los dos parecen números sueltos que memorizar, pero esconden una misma enseñanza: en un runtime donde miles de inquilinos comparten un proceso, tu presupuesto no es una máquina entera reservada para ti, sino una porción que debes gastar con la disciplina de quien sabe que el vecino respira el mismo aire.

128 MB por isolate, no por petición

Cada isolate puede consumir hasta 128 megabytes de memoria, y ahí dentro cabe todo: el heap de JavaScript y las asignaciones de WebAssembly. El matiz que lo cambia todo es que ese límite es por isolate, no por invocación. Un mismo isolate atiende muchas peticiones a la vez, y todas ellas comparten esos 128 MB.

La consecuencia es sutil y peligrosa. Un endpoint que carga en memoria un fichero de 40 MB puede funcionar de maravilla cuando lo pruebas solo, y reventar en producción cuando tres peticiones coinciden en el mismo isolate y suman 120. No razonas sobre el pico de una petición aislada, sino sobre la suma de las que pueden solaparse.

Cuando un isolate supera los 128 MB, el runtime deja terminar las peticiones en vuelo y crea un isolate nuevo para las siguientes; bajo carga extrema, puede llegar a cancelar peticiones entrantes para mantener la estabilidad. En tu código, el síntoma es el error de memoria excedida.

Qué es un subrequest y cuántos caben

Un subrequest es cualquier petición que tu Worker lanza hacia afuera: una llamada con fetch() a un recurso de Internet, o una operación contra un servicio de Cloudflare como R2, KV o D1. Todas cuentan contra el mismo presupuesto.

Los números dependen del plan. En Free tienes 50 subrequests externos por invocación, más 1000 hacia servicios internos de Cloudflare. En Paid, el límite por defecto es de 10000 por invocación —el viejo tope de 1000 se levantó en 2026— y puedes subirlo hasta diez millones con limits.subrequests para cargas largas como websockets sobre Durable Objects o Workflows extensos.

{
  "limits": {
    // sube el techo de subrequests para cargas muy largas
    "subrequests": 50000
  }
}

Dos precisiones importan. La primera: cada salto de una cadena de redirecciones cuenta como un subrequest, así que el total puede superar el número de llamadas fetch() que ves escritas en tu código. La segunda, y más determinante para el diseño: solo puedes tener seis conexiones salientes abiertas a la vez. Puedes hacer diez mil subrequests a lo largo de una petición, pero no más de seis viajando en paralelo en un instante dado.

// abanico de 100 llamadas, pero como maximo 6 a la vez
async function enLotes<T>(tareas: (() => Promise<T>)[], limite = 6) {
  const salida: T[] = [];
  for (let i = 0; i < tareas.length; i += limite) {
    const lote = tareas.slice(i, i + limite).map((t) => t());
    salida.push(...(await Promise.all(lote)));
  }
  return salida;
}

Diseñar dentro de los dos límites

La memoria y los subrequests empujan hacia el mismo estilo de código, y no es casualidad: los dos premian no acumular. La técnica central es el streaming. En vez de traer un objeto entero de R2 a memoria para transformarlo y devolverlo, encadenas el cuerpo de la respuesta como un flujo que pasa por el Worker sin residir del todo en él.

export default {
  async fetch(request, env): Promise<Response> {
    const objeto = await env.MI_BUCKET.get("video-grande.mp4");
    if (!objeto) return new Response("no encontrado", { status: 404 });

    // el cuerpo fluye a traves del Worker: no se acumula en los 128 MB
    return new Response(objeto.body, {
      headers: { "content-type": "video/mp4" },
    });
  },
};

Para los subrequests, el patrón es acotar el abanico. Un Worker que consulta cien recursos no debe dispararlos todos a la vez —chocaría contra las seis conexiones— ni uno tras otro en serie —desperdiciaría la latencia—: los agrupa en lotes de seis, como en la función de más arriba. Y el trabajo que deba sobrevivir a la respuesta, como escribir métricas, lo entrega a ctx.waitUntil() para no bloquear al usuario.

flowchart TB
ISO[Un isolate con 128 MB compartidos] --> R1[Peticion A en vuelo]
ISO --> R2[Peticion B en vuelo]
ISO --> R3[Peticion C en vuelo]
R1 --> SUM[La memoria usada es la suma de todas]
R2 --> SUM
R3 --> SUM
SUM --> GATE{Supera 128 MB}
GATE -- si --> KILL[Isolate reciclado y peticiones nuevas a otro]
GATE -- no --> OK[Sigue atendiendo]
style ISO fill:#89b4fa,color:#11111b
style SUM fill:#fab387,color:#11111b
style KILL fill:#f38ba8,color:#11111b
style OK fill:#a6e3a1,color:#11111b