Los límites del modelo

Cada elección arquitectónica tiene un reverso. El isolate compra arranque cero y densidad altísima a cambio de renunciar a cosas que en un servidor tradicional dabas por sentadas: un disco donde escribir, tiempo de CPU sin límite, memoria abundante. Conocer estos límites no es leer la letra pequeña: es entender la forma del modelo para diseñar con él a favor, no contra él. Un Worker no es un servidor recortado; es una pieza de cómputo puro que se acopla a otras piezas.

Sin sistema de archivos persistente

Un isolate no tiene disco. El código que despliegas llega como un bundle de solo lectura, y no existe un /tmp donde escribir algo esperando encontrarlo en la siguiente petición.

La razón es coherente con todo el modelo: hay miles de isolates repartidos por cientos de ubicaciones, creándose y evictándose sin cesar. Un archivo escrito en uno de ellos no tendría ningún sentido para los demás ni sobreviviría a la evicción.

El estado, por tanto, no vive en el cómputo: vive en servicios de almacenamiento pensados para el edge, a los que el Worker accede por bindings.

flowchart TB
W[Worker computo puro sin disco] --> KV[KV lecturas globales]
W --> R2[R2 objetos y blobs]
W --> D1[D1 base SQL]
W --> DO[Durable Objects estado coordinado]
style W fill:#89b4fa,color:#11111b
style KV fill:#a6e3a1,color:#11111b
style R2 fill:#fab387,color:#11111b
style D1 fill:#cba6f7,color:#11111b
style DO fill:#f9e2af,color:#11111b

La regla mental es sencilla: el Worker calcula, el almacenamiento recuerda.

Cada tipo de estado tiene su pieza —lecturas globales en KV, objetos grandes en R2, datos relacionales en D1, estado coordinado con identidad única en Durable Objects—, y elegir bien entre ellas es un tema entero más adelante en el track.

Lo que importa ahora es interiorizar que la ausencia de disco no es una carencia, sino la condición que obliga a separar cómputo de estado de forma limpia.

Un matiz importante: sí puedes usar memoria dentro de una petición, e incluso conservar algo en variables globales entre peticiones del mismo isolate. Lo que no existe es un disco duradero y compartido.

La distinción entre memoria efímera y almacenamiento persistente deja de ser un detalle académico y pasa a ser una de las primeras decisiones de diseño de cualquier Worker.

CPU acotada por petición

Un Worker tiene un límite de tiempo de CPU por invocación. Ojo: es CPU, no tiempo de pared. Esperar a una API lenta durante segundos no cuenta contra ese límite, como viste en el nivel anterior; lo que cuenta es el cómputo real.

Si tu código se pone a calcular sin parar y supera el presupuesto de CPU, el runtime lo detiene. Esto descarta de raíz cierto tipo de trabajo dentro de una sola petición: bucles enormes de procesamiento, transformaciones pesadas de datos gigantes, cómputo científico prolongado.

Una válvula de escape frecuente es diferir el trabajo no crítico más allá de la respuesta, para que el usuario no lo espere:

export default {
  async fetch(request, env, ctx) {
    const respuesta = Response.json({ ok: true });
    // El trabajo secundario corre tras responder, sin retrasar al usuario:
    ctx.waitUntil(registrarMetrica(env, request));
    return respuesta;
  },
};

Memoria limitada por isolate

Cada isolate dispone de un techo de memoria del orden de 128 MB. Es generoso para cómputo puro y respuestas normales, pero castiga un patrón muy común: cargar algo grande entero en memoria.

Descargar un archivo de cientos de megabytes a una variable, acumular una respuesta enorme antes de enviarla o construir estructuras gigantescas provoca que el isolate se quede sin memoria y sea evictado.

La solución idiomática es transmitir en flujo: procesar los datos a medida que pasan, sin retenerlos todos a la vez.

export default {
  async fetch(request, env, ctx) {
    const origen = await fetch("https://ejemplo.com/archivo-grande");

    // MAL: acumula todo el archivo en memoria del isolate
    // const todo = await origen.arrayBuffer();

    // BIEN: reenvia el cuerpo como flujo, sin retenerlo entero
    return new Response(origen.body, {
      headers: { "content-type": "application/octet-stream" },
    });
  },
};

La Streams API es aquí la herramienta central: te deja leer, transformar y escribir datos por trozos, con una huella de memoria constante sin importar el tamaño total.

Pensar en flujos en vez de en buffers es uno de los cambios de mentalidad más rentables al programar en el edge, y el que mejor escala cuando los datos crecen sin límite.

Otras fronteras y la mentalidad que imponen

Más allá de disco, CPU y memoria, hay fronteras menores que conviene tener en el mapa desde el principio. Ninguna es un obstáculo si diseñas con ella; todas duelen si las descubres tarde.