Arquitecturas de datos: cómo gestionar el backpressure cuando el pipeline consume APIs a distinta velocidad
Arquitecturas de datos: cómo gestionar el backpressure cuando el pipeline consume APIs a distinta velocidad
El pipeline funciona. Las APIs responden. El sistema, en apariencia, está bajo control. Y entonces llega un pico de volumen —una tendencia, un evento, un ciclo de análisis más amplio de lo habitual— y el consumidor empieza a acumular datos más rápido de lo que los puede procesar. La cola crece. La memoria se presiona. El sistema no falla de golpe: se degrada en silencio.
Ese fenómeno tiene nombre: backpressure. Y es uno de los problemas más subestimados en arquitecturas que dependen de APIs externas de datos para alimentar pipelines analíticos. No lo resuelve aumentar la capacidad del servidor. Lo resuelve entender dónde está el cuello de botella y diseñar el pipeline para que la presión retroceda de forma controlada hacia la fuente, en lugar de acumularse de forma invisible hasta que el sistema colapsa.
Este post describe cómo diseñar esa gestión de forma práctica, sin abstracciones vacías.
Por qué el backpressure aparece antes de lo que esperas
La mayoría de los pipelines se diseñan pensando en el caso promedio. Se estima el volumen típico de señales, se dimensiona el procesador, se fija el intervalo de llamadas a la API. Todo encaja sobre el papel.
El problema es que el universo público de Internet no produce señales a ritmo constante. Un evento relevante puede multiplicar por diez el volumen de menciones en cuestión de minutos. Si el pipeline consume datos a demanda —es decir, si el ritmo lo marca el productor, no el consumidor— ese pico llega entero al buffer sin que el procesador tenga tiempo de digerir lo anterior.
El resultado es predecible: el buffer se llena, el procesador empieza a descartar o a reintentar, y los datos derivados que salen del pipeline pierden coherencia temporal. En análisis de tendencias o sentiment analysis, eso no es un problema menor: es un error sistémico que contamina el resultado.
La diferencia entre limitar la tasa y gestionar la presión
Muchos equipos confunden el rate limiting con la gestión de backpressure. Son herramientas distintas con objetivos distintos.
El rate limiting controla cuántas peticiones haces a la API por unidad de tiempo. Protege la fuente de datos y respeta los contratos de uso. Es necesario, pero no es suficiente: limitar cuánto consumes no resuelve qué haces con lo que ya tienes en el buffer.
El backpressure, en cambio, es un mecanismo de señalización que va en dirección contraria al flujo de datos. Cuando el consumidor está saturado, le comunica al productor —o al componente anterior del pipeline— que reduzca la velocidad de emisión. No descarta. No acumula sin límite. Ralentiza el ingreso de datos de forma proporcional a la capacidad de procesamiento disponible.
En la práctica, esto implica diseñar el pipeline con al menos tres elementos explícitos:
- Un buffer acotado, no ilimitado. Si el buffer no tiene límite, el backpressure no tiene dónde materializarse: el sistema simplemente acumula hasta que la memoria explota.
- Una señal de saturación que el consumidor pueda emitir hacia arriba. En sistemas basados en colas (Kafka, RabbitMQ, Redis Streams), esto se traduce en consumer lag visible y gestionable. En pipelines síncronos, puede ser tan simple como devolver un código de estado al componente orquestador.
- Una política de respuesta en el productor: pausar, ralentizar o encolar en origen. Sin esta política, la señal de saturación no tiene efecto.
Estrategias concretas según el tipo de pipeline
No todos los pipelines tienen la misma topología. La estrategia de backpressure depende de cómo se estructura el flujo.
Pipeline basado en pull (el consumidor pide datos a la API): Aquí el control es más directo. El consumidor puede simplemente dejar de pedir hasta que procese lo que tiene. El riesgo está en que algunos datos tienen ventana de relevancia: si el análisis es de tendencias en tiempo casi real, pausar el pull demasiado tiempo introduce retardo analítico. La solución es fijar un umbral de buffer a partir del cual el intervalo de pull se amplía de forma progresiva, no binaria (pause/go), sino escalonada.
Pipeline basado en push (la API o un webhook emite datos sin que el consumidor lo solicite):
El control es más complejo porque el flujo viene desde fuera. Aquí el buffer acotado es crítico: cuando se llena, el sistema debe devolver un 429 o equivalente al emisor, o bien redirigir el exceso a una cola de overflow con TTL definido. Sin esa válvula, el push incontrolado destruye el pipeline.
Pipeline mixto con múltiples fuentes de APIs: Es el escenario más común en entornos B2B reales. Diferentes APIs producen señales a velocidades distintas. El consumidor central recibe flujos asimétricos. En este caso, el backpressure debe implementarse por carril: cada fuente tiene su propio buffer y su propia señal de saturación, y el orquestador central gestiona prioridades cuando varios carriles se saturan a la vez. La priorización debe estar definida antes de que ocurra el pico, no improvisada en caliente.
Lo que no se puede ignorar: la coherencia temporal del dato
Un pipeline que gestiona mal el backpressure no solo pierde rendimiento. Pierde coherencia temporal. Los datos que finalmente procesa corresponden a momentos distintos, mezclados sin orden claro. En análisis derivado —sentiment, detección de tendencias, monitorización de menciones— eso significa que el resultado no refleja ningún momento real: es un artefacto del retraso del sistema.
Por eso, cualquier arquitectura que consuma señales del universo público a través de APIs externas —como las que expone FeedScale— necesita incluir timestamps de ingesta y timestamps de origen como campos de primera clase, no como metadatos opcionales. Cuando el backpressure introduce latencia, la diferencia entre ambos timestamps es la única forma de saber qué parte del análisis es fiable en tiempo real y qué parte es análisis diferido.
El backpressure como contrato de diseño, no como parche operativo
El error más frecuente es añadir gestión de backpressure después de que el sistema ya ha fallado. Se implementa como parche: se aumenta el buffer, se añade un reintento con espera exponencial, se monitoriza el lag de la cola. Funciona hasta el siguiente pico.
La gestión de backpressure debe ser una decisión de diseño en la fase de arquitectura, no una corrección operativa. Implica definir explícitamente cuál es la capacidad máxima de procesamiento sostenida, cuál es el comportamiento del sistema cuando se supera, y quién es responsable de comunicar la saturación a cada componente del pipeline.
Esas tres preguntas, respondidas antes de poner el primer mensaje en la cola, ahorran incidentes que tardan horas en diagnosticar y días en recuperar.
Un pipeline que sabe retroceder bajo presión es más robusto que uno que simplemente procesa más rápido. La velocidad sin control de flujo no es una arquitectura: es una cuenta regresiva.