Backpressure

Qué es

Backpressure es la propagación de presión hacia upstream cuando downstream no puede mantener el ritmo de trabajo. El receptor o una etapa intermedia comunica disponibilidad limitada y el productor modifica su emisión, espera o adquisición de nuevas tareas. La propiedad relevante es que la presión influya en quien genera carga; una señal ignorada no regula el sistema.

Producer -> bounded stage -> Consumer
    <- reduced demand / unavailable credits / blocking

Puede ser explícita, mediante demanda o créditos, o implícita, mediante una operación que no progresa hasta disponer de espacio. Aquí se usa el término para describir esa relación de feedback. Networking, streaming y messaging emplean vocabularios parcialmente distintos; no toda señal de congestión se denomina backpressure en cada disciplina.

Problema y frontera

Un consumidor capaz de completar 120 operaciones por segundo no puede sostener indefinidamente un productor que envía 300. Si upstream continúa sin reacción, el excedente crece en algún lugar, se rechaza o se pierde. Backpressure permite ajustar el ritmo cuando los participantes cooperan y el origen puede desacelerar.

Eso no implica garantizar aceptación de toda la demanda. Una persona puede seguir enviando pedidos y un sensor puede seguir generando muestras aunque el servicio no tenga capacidad. Si el origen no puede pausar, se necesita un contrato de almacenamiento acotado, rechazo o pérdida permitida. La señal no elimina ese límite físico.

Tampoco crea capacidad: preserva condiciones de progreso reduciendo presión. El resultado puede ser menor tasa de ingreso, mayor espera del productor o rechazo más temprano. La elección depende de qué obligaciones ya existen y dónde puede acumularse trabajo sin romperlas.

Formas de comunicar presión

Mecanismo	Cómo afecta upstream	Condición necesaria
Demand signalling	Emite solo la cantidad solicitada.	El emisor respeta la demanda.
Pull	Obtiene otra tarea cuando puede atenderla.	No hay prefetch ilimitado oculto.
Créditos	Deja de enviar al agotarse el permiso.	Créditos y liberación corresponden al recurso real.
Blocking	La escritura o entrega espera por espacio.	La espera no impide liberar capacidad.
Acknowledgements	La falta de confirmaciones frena nuevos envíos bajo una ventana.	La ventana es finita y el ack tiene semántica clara.
Rechazo con feedback	El productor reduce emisión al detectar presión.	Existe una política de reacción, no solo un error.

Reactive Streams propone intercambio asíncrono con backpressure no bloqueante. Su especificación relaciona emisiones con demanda del subscriber, lo que permite regular un flujo sin dedicar necesariamente un thread a esperar. Reactive Streams JVM specification.

Un ack de transporte puede permitir enviar otro mensaje aunque su efecto de negocio siga pendiente. Solo regula el recurso asociado a esa confirmación. Retener acks arbitrariamente puede provocar redelivery o expiración; no conviene inventar semántica de control por fuera del protocolo.

Buffers y propagación entre etapas

Un buffer acotado permite desacoplar pequeñas diferencias temporales. Cuando se llena o disminuye su margen, la etapa debe reducir demanda, bloquear bajo un límite válido o aplicar la política de rechazo. Backpressure no equivale a una cola infinita. Esta última puede ocultar presión mientras acumula memoria, edad y obligaciones imposibles de resolver a tiempo.

En Producer → A → B → Consumer, regular solo B → Consumer no garantiza que A deje de aceptar. Si B mueve todo a una cola interna ilimitada, rompe la propagación práctica. Cada etapa necesita relacionar su demanda upstream con lo que mantiene en espera y en ejecución, no únicamente con lo que ya entregó.

queue-management organiza lo pendiente y flow-control puede limitar lo que cruza una frontera. Backpressure describe cómo esa regulación o señal provoca una respuesta hacia el origen. Buffering y feedback pueden coexistir, pero mover trabajo de memoria local a un broker no prueba que la presión haya llegado al productor.

Diferencias e interacción

Backpressure no equivale a rate-limiting. Una cuota fija de 100 req/s puede aplicarse con el consumidor vacío; una reducción por consumidor saturado depende de su estado. Un limitador adaptativo puede ser un mecanismo de respuesta a presión, sin hacer equivalentes ambos conceptos.

bulkhead limita consumo por grupo. Su saturación puede producir feedback, pero un error por permiso agotado no asegura que upstream desacelere. Google SRE describe throttling del lado cliente en respuesta a rechazos, mostrando que la reacción del productor también forma parte de la protección. Handling Overload.

retry-topologies importa cuando una entrega fallida vuelve a circular. Una retry queue puede espaciar trabajo y aun así aumentar backlog total. Pausar nuevas adquisiciones no sirve si otros workers o retries internos siguen enviando sin presupuesto. retry, backoff y jitter deben respetar la presión y la identidad de la intención, sin constituir una receta universal.

Ejemplo transversal

En API Gateway → Order → Payment, 100 req/s son sostenibles y Payment ofrece capacidad aproximada de 120. Durante un pico de 300, Payment puede disminuir créditos o informar falta de disponibilidad. Order reduce llamadas nuevas y evita llenar su buffer; si Gateway y el cliente cooperan, la presión puede llegar más arriba.

El alcance se corta donde no existe cooperación. Un Gateway que responde rechazo pero recibe inmediatamente la misma solicitud repetida no ha conseguido desaceleración útil. Si la espera agota recursos de etapas anteriores, la presión puede participar en cascading-failures; comunicar saturación no garantiza contención. Necesita límites propios y una política de admission-control o load-shedding cuando no puede absorber más trabajo.

Fallos, trade-offs y evaluación

Blocking puede causar deadlock si ocupa todos los workers que también necesitan procesar las tareas que liberarían espacio. En un grafo con ciclos, varias etapas pueden esperar unas por otras. Es necesario conservar caminos de progreso para completar, cancelar y devolver créditos.

Feedback retrasado y reacción excesiva pueden producir oscilaciones: llenar, frenar todo y volver a liberar una oleada. Márgenes, granularidad y tiempos de respuesta deben corresponder al sistema observado. La espera también consume deadline, aunque reduzca presión downstream.

Usarlo en pipelines cooperativos con demanda variable y límites claros. No confiar en él como único control frente a productores no cooperativos o fuentes que no pueden detenerse. Medir buffers, edad, demanda pendiente, créditos, tiempo bloqueado y producción original permite comprobar dónde la presión realmente se propaga y dónde solo se desplaza.