Backpressure en sistemas: qué es y cómo diseñarla

Backpressure es un mecanismo de control para que un productor reduzca o pause el ritmo cuando el consumidor no puede procesar los datos que recibe. Sin esa señal, una cola puede crecer hasta agotar memoria o aumentar la latencia. La idea aparece en streams de archivos, transformaciones, colas de mensajes y respuestas que llegan por partes.

También puede servirte: Server-Sent Events: qué son y cuándo convienen

La señal puede ser explícita o estar incorporada en la API. En Node.js, write() puede devolver false cuando el búfer alcanzó su límite y el productor debe esperar el evento drain. En Streams API del navegador, las colas y estrategias de sizing ayudan a coordinar la velocidad entre las etapas.

Usá backpressure cuando el origen puede producir ráfagas o cuando la capacidad del destino varía: cargas de archivos, exportaciones grandes, procesamiento de logs, pipelines de imágenes o consumidores de una cola. El objetivo es mantener un límite conocido de trabajo pendiente y proteger al sistema durante los picos.

En un broker, repartir mensajes entre consumidores aumenta la capacidad, pero no elimina la necesidad de controlar el ritmo. Si el procesamiento se retrasa, podés limitar la cantidad de mensajes en vuelo, pausar la lectura o derivar fallos a una cola separada. La política depende de si los datos se pueden reintentar, descartar o reconstruir.

Definí un límite de búfer y una señal única para frenar al productor. Cuando el consumidor se recupera, reanudá desde esa señal y evitá aceptar trabajo nuevo sólo porque la memoria todavía tiene espacio. En un stream, propagá la pausa a todas las etapas para que una transformación lenta no quede escondida detrás de otra cola.

Elegí qué ocurre al alcanzar el límite: esperar, rechazar con un error recuperable, persistir en una cola o aplicar una política de descarte documentada. Registrá el identificador del mensaje y hacé idempotente el consumidor si puede haber reintentos. Una prueba útil es inyectar una etapa lenta y verificar que memoria, latencia y recuperación respeten los límites definidos.

Una cola ilimitada sólo traslada el problema: el proceso parece aceptar trabajo hasta que el tiempo de respuesta y el uso de memoria se disparan. También puede ocurrir lo contrario, cuando se descartan datos sin informar al productor y la aplicación queda incompleta. Los timeouts y reintentos deben tener límites para no crear una segunda ráfaga.

Medí tamaño y edad de la cola, tasa de producción y consumo, tiempo de espera, bytes en vuelo, rechazos y reintentos. Compará esos datos con la capacidad real del consumidor y documentá qué mensajes se pueden recuperar. La implementación correcta hace visible la presión y permite decidir entre esperar, escalar o degradar una función.