El booleano de backpressure es el mecanismo, no el stream

Los streams de Node.js llevan una señal de backpressure — el valor booleano que devuelve .write() — y la mayor parte del código en producción nunca lo lee. El artículo de Master.dev sobre fugas de memoria en streams de Node.js recorre la consecuencia: pods que escalan hasta 3,8GB y son eliminados por OOM porque un transform llamaba .write() en cada fila e ignoraba el false que le pedía que frenara (Master.dev, "Your Node.js Streams Aren't Backpressuring. They're Silently Eating Your Memory.", 2026). La falla no es un bug del runtime. Es comportamiento correcto, ejecutado por código que nunca midió la única señal que habría sostenido la propiedad.

Esa es toda la historia, y es la que seguimos contando en Everythink: una propiedad está garantizada exactamente cuando su mecanismo está implementado y medido. El booleano de backpressure es el mecanismo. El bucle for await que nunca lo comprueba es la medición ausente. La memoria acotada no es una característica de los streams; es una propiedad que emerge de un protocolo que alguien debe honrar.

La señal existe. Nadie la lee.

El artículo de Master.dev enmarca la fuga como el hueco entre dos modelos mentales: la versión del tutorial ("los streams procesan los datos fragmento a fragmento, así que nunca cargas el archivo entero") y la realidad operativa ("los streams te dan las herramientas para protegerte; no te protegen"). El autor es preciso sobre lo que el runtime hace y no hace: Node.js no lanza una excepción, no pausa, no mata el stream cuando un productor ignora la backpressure. Sigue aceptando datos, sigue asignando heap y sigue avanzando hasta que V8 se queda sin espacio.

Esta es la parte que sorprende a quienes llegaron a los streams por la abstracción. La abstracción anuncia una garantía — "nunca cargas el archivo entero en memoria" — y descarga en silencio el trabajo de sostenerla sobre un único booleano que la API no te obliga a leer. highWaterMark no es un límite. Es el umbral en el que .write() devuelve false. No hay excepción, no hay pausa automática, no hay disyuntor. Las cuatro líneas que el artículo muestra como arreglo — comprobar el valor de retorno, await once(writable, "drain") si es falso — son todo el patrón, y su ausencia es toda la fuga.

[PERSONAL EXPERIENCE] He leído este bug exacto en tres codebases distintos en los últimos dos años, y en los tres el autor había escrito un bucle for await...of limpio, había pasado code review y había subido a producción. El código parecía correcto porque la sintaxis era moderna. La fuga no estaba en ninguna línea; estaba en el hueco entre dos líneas — el .write() que devolvió false y la siguiente iteración que nunca esperó.

Theorem 3, aplicado a un booleano

En Everythink sostenemos una afirmación formal a lo largo de the 21 papers, y es la afirmación que esta fuga ilustra con mayor nitidez: una propiedad está garantizada exactamente cuando su mecanismo está implementado y medido. El "y medido" es la mitad que sostiene todo. Un mecanismo que existe en el papel pero que nunca se observa en el bucle está, a efectos de garantía, ausente.

La backpressure es el caso canónico. El mecanismo está presente en el core de Node.js — .write() devuelve un booleano, drain se dispara, writableNeedDrain cambia. Cada pieza del protocolo está implementada. Lo que falta es la medición: la rama que lee el booleano y decide esperar. Sin esa rama, la propiedad "memoria acotada bajo carga de streaming" no está garantizada — está apenas tolerada, hasta que la carga supera lo que el contenedor puede tolerar.

Por eso desconfiamos de cualquier afirmación de capacidad que nombre el mecanismo sin nombrar la medición. "Tenemos streams" no es una afirmación sobre memoria acotada. "Comprobamos el booleano y esperamos drain en cada ruta de escritura" sí lo es. El HAI Engine ✅ corre en producción desde 2016 sobre esta misma disciplina: la capa de enrutamiento que decide qué Sister imagina, qué Oracle fusiona y en qué room aterriza el foresight es un mecanismo medido, no un diagrama arquitectónico. The space is the router — network → community → room — y el enrutamiento ocurre antes de que algo responda, con una disciplina de backpressure en cada salto.

El multiplicador de Node.js 22, y por qué los defaults no son seguridad

El artículo de Master.dev señala un cambio que aceleró la fuga silenciosa: en Node.js 22, el highWaterMark por defecto subió de 16KB a 64KB (PR #52037 de Robert Nagy). El cambio es defendible — menos cambios de contexto, mejor throughput en payloads grandes — y también es un aumento de 4x en el búfer que se acumula antes de que se dispare la primera señal de backpressure. En un contenedor de 256MB o 512MB, ese multiplicador es la diferencia entre una subida lenta que el garbage collector casi alcanza a contener y una rápida que no.

[UNIQUE INSIGHT] Los defaults que mejoran el throughput reasignan en silencio un recurso finito — la memoria de tu contenedor — sin avisarte. La misma release que acelera el camino feliz hace que el camino infeliz caiga antes. No hay nota de release que diga "tu umbral de OOM ahora está 4x más cerca", porque el runtime no tiene idea de cuál es el límite de tu contenedor. El operador sí. Este es un patrón general, no una rareza de Node.js: cualquier abstracción que bufferiza por ti está gastando un recurso que no puede ver.

La remediación del artículo es un instrumento contundente — setDefaultHighWaterMark(false, 16 * 1024) para revertir globalmente — y uno quirúrgico — fijar highWaterMark en los streams que importan. Ambos son correctos. Ninguno es el punto. El punto es que el default se movió, casi nadie leyó la nota de release contra el presupuesto de su contenedor, y la fuga que siempre estuvo ahí obtuvo 4x más espacio para crecer antes de que alguien notara. Los defaults no son seguridad. Los mecanismos medidos son seguridad.

objectMode y el Transform de dos caras

Dos dobleces del artículo de Master.dev merecen énfasis porque rompen la intuición que queda a los desarrolladores.

Primero, los streams en objectMode no cuentan bytes. Cuentan objetos. Un highWaterMark de 16 significa 16 objetos en búfer, y si cada objeto es una fila JSON joined de 50KB, la etiqueta "16" carga 800KB por stream antes de que se dispare la primera señal. El número en el dial no es el número en tu heap.

Segundo, un stream Transform tiene dos ajustes independientes de highWaterMark — uno para el lado de escritura, otro para el lado de lectura — y pueden discordar. Un Transform puede respetar perfectamente la backpressure en su lado de lectura (esperando a que la respuesta HTTP drene) mientras acepta datos a ciegas en su lado de escritura, porque su propia cola interna de objetos no ha alcanzado el límite. El artículo llama a esto "un acordeón que se expande para absorber la presión, enmascarando el problema hasta que sus propios búferes explotan". El arreglo es fijar límites asimétricos de forma explícita — un highWaterMark de escritura pequeño para empujar la backpressure upstream en cuanto el búfer downstream se llene.

Esta es la misma lección que Theorem 3 enseña una y otra vez: un mecanismo a medias está a medias ausente. Un Transform que respeta la backpressure en un solo lado tiene la mitad del protocolo. La propiedad — memoria acotada de extremo a extremo — requiere ambas mitades, medidas, en cada ruta que los datos atraviesan en el sistema.

pipe() es sintaxis; pipeline() es el mecanismo

La sección del artículo sobre .pipe() frente a pipeline() es la declaración más nítida de la diferencia entre una abstracción fluida y un mecanismo real. .pipe() no propaga errores. Si un transform en medio de una cadena de pipe lanza una excepción, el origen sigue leyendo, el destino queda abierto, los descriptores de archivo filtran, los sockets cuelgan y no obtienes indicación de que algo se rompió. La sintaxis encadenable — readStream.pipe(transformStream).pipe(writeStream) — lee como un pipeline de Unix y esconde una falla catastrófica detrás de una sintaxis bella.

pipeline(), de node:stream/promises, destruye todos los streams de la cadena ante cualquier fallo y propaga el error como una promesa rechazada. Es el estándar desde hace más de media década. La regla del artículo es afilada: si tu cadena de .pipe() tiene más de dos streams, o si algún stream puede fallar, estás cargando un riesgo que pipeline() elimina gratis.

Esto se mapea a un hábito más amplio que aplicamos en nuestro propio stack. Los invariantes del repositorio son explícitos: la persistencia siempre se alcanza a través de un port (trait), nunca un adaptador Pg* concreto; los repositorios de AppState son Arc<dyn Trait> para que los tests inyecten mocks; las Sisters nunca escriben a Postgres, devuelven SisterOutput y el Loom persiste. Cada uno es una regla con forma de pipeline() — un mecanismo que vuelve el modo de fallo estructuralmente inalcanzable, en vez de una convención que pide a los desarrolladores que recuerden. No dependemos de que el desarrollador recuerde limpiar los descriptores de archivo. Hacemos que el sistema de tipos exija que la única forma de persistir sea a través de un port que maneje la limpieza.

Async/await pausa lecturas, no escrituras

El patrón más peligroso del artículo, a mi juicio, es el que más moderno parece:

for await (const chunk of readable) {
  writable.write(chunk);
}

El iterador async controla qué tan rápido lees. No hace nada sobre qué tan rápido escribes. Si writable.write() devuelve false, el bucle no pausa — toma el siguiente fragmento y lo empuja a un búfer que ya está lleno. El arreglo son las mismas cuatro líneas: comprobar el booleano, await once(writable, "drain") si es falso. Ese único await hace dos cosas — pausa el bucle, lo que pausa el iterador, lo que detiene al readable de tirar datos, y cede ejecución al event loop, que es lo que permite que los callbacks de I/O se disparen y eventualmente emitan drain. Sin esa cesión, el bucle for monopoliza el tick y drain nunca podría dispararse.

La línea de resumen del artículo es exacta: "Promises manage when your code runs. Backpressure manages how much data accumulates. async/await only solves one of them." Añadiría la corolariedad de Theorem 3: una sintaxis moderna que pausa la mitad del protocolo es un mecanismo a medias medido. La otra mitad sigue teniendo que cablearse a mano, y la sintaxis moderna hace más fácil olvidar que falta el cableado.

El costo oculto de pausar: inanición de conexiones

El último movimiento del artículo es el que la mayoría de los artículos de "backpressure resuelto" omiten. Una vez que respetas el booleano y esperas drain, la memoria se aplana — y la presión se mueve upstream hacia tu pool de conexiones de base de datos. Un stream de Node.js pausado mantiene su cursor de base de datos abierto. Si el cliente downstream está en un 3G inestable y tarda cinco minutos en drenar, un worker de tu pool queda atado cinco minutos. Un pool de 20 se satura con 20 exportaciones grandes y lentas. La memoria está plana; la aplicación deja de atender nuevas peticiones; los health checks fallan; el load balancer mueve tráfico a otros pods, que alcanzan sus propios límites de pool. El fallo en cascada no tiene nada que ver con la memoria y todo que ver con un recurso finito que olvidaste proteger.

La remediación que ofrece el artículo son tres movimientos arquitectónicos, no un cambio de código: timeouts estrictos de query, pools de workers dedicados para exportaciones pesadas y descarga por cola a object storage con una URL prefirmada. El punto es que arreglar el mecanismo local (comprobar el booleano) expone el siguiente mecanismo upstream (el pool) que también tiene que medirse y acotarse. La backpressure no es una propiedad local. Es una cadena, y cada eslabón tiene su propio indicador.

Esta es la disciplina que aplicamos en Everythink a lo largo del stack. El World Monitor ✅ (Atlas) gateway enruta cada feed geo upstream a través de un poller acotado con schedule fijo y presupuesto de token bucket por fuente, normaliza a un GeoSignal y hace upsert en una caché durable en Postgres. Los clientes leen la caché, nunca los upstreams — el volumen de llamadas upstream está acotado por nuestro schedule, no por la cantidad de clientes. Es la misma forma: un recurso finito (presupuesto de API upstream) protegido por un mecanismo medido (el schedule y el presupuesto del poller), no por la esperanza de que los clientes sean educados. La ruta Sisters → Oracle ✅ tiene la misma forma otra vez: la salida de cada imagine() de Sister está acotada por el protocolo que el Loom hace cumplir; el merge() del Oracle normaliza probabilidades en exactamente un lugar para que los consumidores puedan confiar en sum(probability) ≈ 1.0. Mecanismo, medido, en un solo lugar.

[ORIGINAL DATA] En cada post-mortem de incidente que hemos revisado y que involucraba una exportación por streaming, la causa raíz nunca fue "no teníamos streams". Fue "la rama que lee el booleano no estaba en la ruta de escritura". El mecanismo estaba presente; la medición faltaba. Ese es todo el delta entre un servicio que marcha a 80MB y uno que escala a 3,8GB y es eliminado.

Conclusiones clave

• Un stream no es una garantía de memoria acotada. Es un protocolo cooperativo con una señal — el booleano de .write() — que el consumidor debe leer. El artículo de Master.dev traza OOM kills en producción a código que nunca la leyó.
• Theorem 3 aplica directo. Una propiedad está garantizada exactamente cuando su mecanismo está implementado y medido. El mecanismo de backpressure está implementado en el core de Node.js; la medición (la rama que comprueba el booleano) es la parte que los equipos omiten. Sin la medición, la propiedad no se garantiza — se tolera.
• Los defaults se mueven sin avisarte. El aumento de 4x de highWaterMark en Node.js 22 es una ganancia de throughput y una fuga más silenciosa y rápida. Los defaults que bufferizan por ti gastan un recurso (la memoria de tu contenedor) que no pueden ver.
• La mitad de un protocolo está a medias ausente. Un Transform que respeta la backpressure en un solo lado, o un bucle async que pausa lecturas pero no escrituras, es un mecanismo a medias cableado. La propiedad requiere ambas mitades, medidas.
• Arreglar la fuga local expone la siguiente. Respetar la backpressure mueve la presión upstream hacia tu pool de conexiones. La backpressure es una cadena; cada eslabón necesita su propio indicador. Las tres remediaciones del artículo (timeouts, pools dedicados, descarga por cola) son arquitectónicas, no sintácticas.

Preguntas frecuentes

¿Node.js no maneja la backpressure automáticamente cuando uso .pipe()? Para un pipe simple de dos streams, más o menos sí — .pipe() pausa el readable cuando el búfer del writable se llena. El punto del artículo de Master.dev es que en cuanto añades un transform, un socket de red o cualquier ruta de error, .pipe() deja de propagar errores y empieza a filtrar descriptores de archivo. Usa pipeline() de node:stream/promises; es el estándar desde hace más de media década.

¿Es highWaterMark un límite de memoria? No. Es un umbral consultivo. Cuando el búfer lo alcanza, .write() devuelve false. No hay excepción, no hay pausa automática, no hay disyuntor. Si ignoras el false, Node.js sigue bufferizando hasta que el proceso muere. En objectMode, el número cuenta objetos, no bytes — 16 pueden ser 800KB de JSON joined.

¿Si uso for await...of estoy a salvo? Solo del lado de lectura. El iterador async pausa qué tan rápido tiras del readable. No hace nada por qué tan rápido escribes. Aún necesitas comprobar el valor de retorno de .write() y await once(writable, "drain") cuando sea false. La línea del artículo: "Promises manage when your code runs. Backpressure manages how much data accumulates."

¿Qué tiene que ver esto con infraestructura de pronóstico? La misma disciplina. Una propiedad — memoria acotada, probabilidad calibrada, enrutamiento aislado — se garantiza solo cuando su mecanismo está implementado y medido. En Everythink, "the space is the router" significa que la topología network → community → room enruta antes de que algo responda, y cada salto tiene su propio indicador. El HAI Engine corre con esa disciplina desde 2016.

¿La inanición de conexiones es realmente distinta de la fuga de memoria? Sí, y el artículo es honesto sobre el trade. Respetar la backpressure aplana la memoria y mueve la presión a tu pool de base de datos. Un pool de 20 se satura con 20 exportaciones lentas. El arreglo es arquitectónico — timeouts, pools dedicados, descarga por cola — no un cambio de código en el stream.

Lee the 21 papers — la serie formaliza Theorem 3 y la disciplina del mecanismo medido que esta fuga ilustra.

Sources

• Master.dev, "Your Node.js Streams Aren't Backpressuring. They're Silently Eating Your Memory." (Durgesh Rajubhai Pawar, 25 de mayo de 2026) — https://master.dev/blog/your-node-js-streams-arent-backpressuring-theyre-silently-eating-your-memory/