Backpressure

Resumen

Backpressure es un concepto tomado de la dinámica de fluidos aplicado a sistemas de software. Cuando un productor genera datos más rápido de lo que un consumidor puede procesarlos, el consumidor debe tener una forma de decir «pará, no me mandes más hasta que termine con esto». Sin backpressure, el consumidor acumula trabajo en buffers de memoria que eventualmente se llenan y causan fallas por falta de memoria (out of memory) o latencia descontrolada.

En sistemas reactivos —Reactive Streams, RSocket, Project Reactor, Akka Streams— el backpressure es un concepto de primera clase: el consumidor solicita explícitamente cuántos elementos quiere recibir —pull-based—. En sistemas de mensajería tradicionales —Kafka, RabbitMQ—, el backpressure se implementa limitando el prefetch, pausando consumidores, o usando colas con capacidad acotada.

Alcance y supuestos

Este paquete cubre el concepto a nivel arquitectónico: qué es, qué problema resuelve, cómo se relaciona con otros patrones del ecosistema, y en qué contexto tiene sentido aplicarlo. No cubre detalles de implementación específicos de cada tecnología ni configuraciones de proveedores cloud concretos. Asume que el lector entiende los fundamentos de sistemas distribuidos y arquitectura de software.

Modelo mental

Una banda transportadora en una fábrica de galletitas. Las galletitas salen del horno a 100 por minuto, pero el empaquetador solo puede procesar 60 por minuto. Sin control, las galletitas se acumulan, se caen de la banda y se rompen. La solución: un sensor que le dice al horno «bajá la velocidad» o una compuerta que frena la banda hasta que el empaquetador se ponga al día. Eso es backpressure.

Uso práctico

• ✅ Protección de memoria: evitar buffers infinitos que consuman toda la RAM.
• ✅ Sistemas reactivos: Reactive Streams, gRPC con flow control, WebSockets con control de flujo.
• ✅ Streaming de datos: consumidores lentos no deberían tumbar productores ni viceversa.

La alternativa sin backpressure es descartar mensajes —dropping— o fallar. En muchos sistemas —telemetría, logs— descartar es aceptable. En sistemas financieros o de salud, no.

Ejemplo trabajado: backpressure en un pipeline de procesamiento

Un servicio ingiere eventos de sensores IoT a 10 000 eventos/segundo. El servicio de procesamiento solo puede manejar 2 000 eventos/segundo. Sin backpressure, los eventos se acumulan en buffers y el servicio termina con OutOfMemoryError. Con backpressure —usando Reactive Streams— el procesador solicita eventos de a 100. Cuando termina esos 100, pide otros 100. El ingestor retiene los eventos en Kafka, donde se acumulan sin pérdida hasta que el procesador se pone al día.

Evidencia

• La especificación Reactive Streams y frameworks como Akka Streams y Project Reactor implementan backpressure como mecanismo central de control de flujo entre productores y consumidores asíncronos.