¿Cómo funciona el backpressure en streams reactivos (especificación Reactive Streams, Project Reactor/RxJava)?

#Por qué los sistemas push necesitan un freno

En una llamada síncrona clásica, el consumidor marca el ritmo: llama a una función, bloquea, y sólo pide más trabajo cuando está listo. Los pipelines reactivos rompen esa garantía por diseño: un Publisher empuja datos de forma asíncrona, y puede producir elementos más rápido de lo que un Subscriber puede consumirlos. Un socket que transmite cotizaciones de mercado, un consumidor de Kafka vaciando una partición caliente, o un cursor de base de datos que corre más rápido que una agregación lenta río abajo son la misma forma de problema: la oferta supera a la demanda, y ese desbalance tiene que aterrizar en algún lado. Sin un mecanismo de control se convierte en un buffer sin límite que termina en un OutOfMemoryError, en datos descartados en silencio, o en un consumidor cada vez más atrasado hasta que todo el pipeline colapsa.

La especificación Reactive Streams —adoptada casi textual en java.util.concurrent.Flow desde Java 9, e implementada por Project Reactor?, RxJava y Akka Streams— resuelve esto con un protocolo híbrido pull-sobre-push construido con cuatro interfaces: Publisher<T>, Subscriber<T>, Subscription y Processor<T,R> (un componente que es ambas cosas). Su única regla rectora es engañosamente simple: un Publisher nunca debe entregarle a un Subscriber más elementos de los que ese Subscriber pidió. La demanda, no la oferta, es la que maneja el flujo.

#El protocolo, paso a paso

1. El Subscriber llama a publisher.subscribe(subscriber).
2. El Publisher llama a subscriber.onSubscribe(subscription), entregando un Subscription — el único canal que tiene el Subscriber para señalar demanda o cancelar.
3. El Subscriber llama a subscription.request(n) para decir "puedo manejar n elementos más ahora mismo".
4. El Publisher llama a onNext(item) como máximo n veces — nunca más que la demanda pendiente sin satisfacer.
5. El ciclo se repite hasta que el Subscriber llama a cancel(), o el Publisher termina el stream con onComplete() o onError(throwable).

#Cuando la demanda no se puede honrar

Un consumidor lento o un productor con picos de tráfico eventualmente van a crear un momento en el que llegan elementos nuevos sin demanda pendiente que los absorba. Las librerías reactivas exponen un puñado de estrategias con nombre justo para ese momento:

#Código: control manual de demanda con Project Reactor

La mayoría del código con Reactor nunca toca request(n) directamente — llamar a .subscribe(consumer) pide implícitamente Long.MAX_VALUE, o sea "sin límite", confiando en que los operadores río arriba igual respeten a un consumidor lento vía buffers internos y operadores como limitRate. Pero cuando necesitás frenar vos mismo a un consumidor lento específico, BaseSubscriber te da el protocolo crudo:

Flux<Long> ticks = Flux.interval(Duration.ofMillis(1))
    .onBackpressureBuffer(
        1000,
        dropped -> log.warn("Dropped tick: {}", dropped),
        BufferOverflowStrategy.DROP_OLDEST
    );

ticks
    .publishOn(Schedulers.parallel())
    .subscribe(new BaseSubscriber<Long>() {

        @Override
        protected void hookOnSubscribe(Subscription subscription) {
            request(10); // demanda inicial: "mandame 10, nada más"
        }

        @Override
        protected void hookOnNext(Long tick) {
            processTick(tick);   // trabajo lento, ej. una escritura a la base
            request(1);          // pedí exactamente uno más cuando estés listo
        }

        @Override
        protected void hookOnError(Throwable error) {
            log.error("El stream de ticks falló", error);
        }
    });

Cada llamada a request(1) sucede recién después de que processTick termina, así que estructuralmente el Publisher no puede adelantarse al consumidor más de un tick. RxJava traza la misma línea entre Observable (sin soporte de backpressure, pensado para secuencias cortas o guiadas por UI) y Flowable (con backpressure completo): Flowable.create(emitter -> { ... }, BackpressureStrategy.BUFFER) elige de entrada uno de los mismos cuatro resultados — BUFFER, DROP, LATEST, ERROR.

🧠 Check your understanding
0/3 · 0/3 answered
1. En el protocolo Reactive Streams, ¿qué se necesita antes de que un Publisher pueda llamar a onNext sobre un Subscriber?
Que el Subscriber haya retornado de onSubscribeQue el reloj interno del Publisher dispareQue exista demanda pendiente de un request(n) previo que todavía no se satisfizo del todoQue termine un ciclo de garbage collection de la JVM
2. ¿Qué estrategia de backpressure encaja con una cotización de precio en vivo, donde sólo importa el valor más fresco y los viejos no sirven?
ERRORDROP sin loggingLATESTBUFFER
3. ¿Por qué un stream de movimiento del mouse nunca puede honrar backpressure de verdad?
Porque Reactor no soporta publishers calientesPorque RxJava exige que todas las fuentes sean fríasPorque la fuente subyacente sigue produciendo sin importar la demanda río abajo, así que los operadores sólo pueden decidir qué hacer con el excedente, no frenar la fuentePorque el backpressure sólo funciona sobre protocolos de red