Arquitecturas de datos: cómo implementar backpressure cuando el proveedor de APIs no avisa de picos
Arquitecturas de datos: cómo implementar backpressure cuando el proveedor de APIs no avisa de picos
El pipeline va bien. Los dashboards son verdes. Y entonces el volumen de señales entrantes se multiplica por cuatro en veinte minutos porque un evento mediático explota en el universo público. El proveedor de APIs responde más lento, tu cola interna se llena, y el componente de procesamiento empieza a descartar mensajes porque nadie diseñó qué debía pasar exactamente en ese momento.
El backpressure no es un problema nuevo. Pero en arquitecturas que dependen de APIs externas para ingerir datos del universo público —menciones, tendencias, señales de medios— la gestión del backpressure tiene un matiz que los libros de texto ignoran: tú no controlas la fuente. No puedes ralentizar al proveedor. Solo puedes controlar cómo tu sistema absorbe, bufferiza y degrada con gracia cuando el flujo supera tu capacidad de procesamiento.
Este post recorre los patrones concretos para implementar backpressure de forma efectiva en este contexto, con decisiones reales que tomar antes de que el pipeline falle en producción.
Por qué el backpressure importa más en ingestión de APIs que en streaming interno
En un sistema de streaming interno —Kafka, Pulsar, RabbitMQ— el productor y el consumidor comparten infraestructura. Puedes aplicar presión negativa directa: el consumidor señaliza que está saturado y el productor reduce la tasa de emisión.
Con una API externa, ese canal de feedback no existe. El proveedor no sabe ni le importa que tu worker está al 95% de CPU. Sigue enviando respuestas al ritmo que tú solicitas, o bien te responde con un 429 Too Many Requests cuando eres tú quien empuja demasiado rápido. En cualquier caso, el control de flujo recae completamente en tu lado.
El problema se agrava cuando el volumen de señales no es uniforme. Un pipeline que procesa menciones de medios puede recibir 300 documentos por minuto en estado normal y pasar a 4.000 durante un evento de alta cobertura. Si tu arquitectura está dimensionada para la media, el pico te rompe.
Patrón 1: cola con capacidad finita y política de rechazo explícita
El error más común es diseñar colas internas sin límite de capacidad. Parece flexible. En realidad es una bomba de memoria de tiempo retardado.
Define una capacidad máxima para cada cola interna y declara explícitamente qué sucede cuando se alcanza ese límite:
- Drop tail: se descartan los mensajes nuevos. Simple, pero pierde señales recientes.
- Drop head: se descartan los mensajes más antiguos. Útil cuando la frescura de la señal importa más que la exhaustividad.
- Backpressure activo: el componente que escribe en la cola espera (bloquea o devuelve error) hasta que haya espacio. Traslada la presión hacia arriba en la cadena.
Para pipelines de media intelligence donde la relevancia temporal es alta, el patrón drop head suele ser la opción menos mala: si no puedes procesar todo, al menos procesa lo más reciente. Pero esto requiere documentarlo en el contrato interno del pipeline, no dejarlo implícito en el comportamiento por defecto del broker.
Patrón 2: separar la capa de ingestión de la capa de procesamiento con buffers desacoplados
Uno de los errores de diseño más costosos es unir ingestión y procesamiento en el mismo proceso. Cuando el procesamiento se ralentiza —porque un modelo NLP tarda más, porque una base de datos responde lento, porque hay un pico de escrituras— bloquea también la ingestión, y empiezas a perder señales en la fuente.
La separación mínima viable es:
- Ingestor: llama a la API externa, deserializa la respuesta, escribe en una cola durable. Sin lógica de negocio.
- Buffer durable: Kafka, Redis Streams, o incluso PostgreSQL con una tabla de trabajo. El punto clave es que sobrevive a reinicios.
- Procesador: lee del buffer a su propio ritmo. Aplica enriquecimiento, análisis derivado, filtrado semántico.
Con este diseño, el backpressure se gestiona en el buffer. El ingestor puede seguir escribiendo aunque el procesador esté saturado, hasta el límite de retención del buffer. Y el procesador puede escalar horizontalmente sin tocar el ingestor.
El coste es operacional: tienes más componentes que mantener. Pero el coste de no tenerlos es un pipeline que falla en silencio durante los momentos de mayor valor informativo.
Patrón 3: circuit breaker asimétrico orientado a APIs externas
El circuit breaker clásico corta el flujo cuando el servicio externo falla. El problema en ingestión de señales es que un circuit breaker mal calibrado puede cortarte el acceso a datos justo cuando más los necesitas: durante un evento mediático de alta intensidad, la API puede responder más lento sin estar caída.
Diseña el circuit breaker con dos umbrales separados:
- Umbral de degradación: la latencia sube por encima de X ms. El circuit breaker no corta, pero activa el modo de ingestión reducida: menos llamadas por unidad de tiempo, priorización de fuentes de mayor impacto.
- Umbral de corte: errores sostenidos por encima del Y% durante Z segundos. Solo entonces se abre el circuito.
Durante el modo de ingestión reducida, el pipeline sigue funcionando con menor cobertura pero sin colapsar. Cuando el circuito se abre completamente, activa un mecanismo de replay desde el último offset conocido en cuanto el servicio se recupere.
Este diseño requiere que la API con la que trabajas exponga offsets o cursores de paginación estables. Plataformas como FeedScale orientan su modelo de acceso precisamente a este tipo de patrones: consumo incremental y reproducible, no llamadas one-shot sin estado.
Patrón 4: métricas de presión como señales de primer nivel
La mayoría de los equipos monitorizan el pipeline con métricas de resultado: documentos procesados por minuto, errores, latencia media. Son útiles para detectar problemas ya ocurridos.
Las métricas de presión son distintas: miden el estado del sistema antes de que el problema se materialice.
Implementa al menos estas tres:
- Queue depth lag: cuántos mensajes hay en cada cola interna. Un lag creciente sostenido indica que el procesador no da abasto.
- Ingest-to-process ratio: ratio entre la tasa de ingestión y la tasa de procesamiento. Si supera 1.0 de forma sostenida, el buffer se está llenando.
- Backpressure events per minute: cuántas veces el ingestor ha tenido que esperar o rechazar porque la cola estaba llena. Si esta métrica pasa de cero, algo aguas abajo está saturado.
Con estas métricas en un dashboard operacional, el equipo puede actuar de forma proactiva: escalar el procesador, activar filtros de prioridad, o simplemente entender qué está pasando antes de que el pipeline empiece a perder datos.
Antes de que llegue el próximo pico
El backpressure no se diseña durante un incidente. Se diseña en el momento en que defines la arquitectura, y se prueba antes de que el evento que lo dispara ocurra en producción.
El ejercicio mínimo es un test de carga con volumen dos o tres veces superior al pico histórico más alto que hayas observado. No para dimensionar infinitamente el sistema, sino para saber exactamente qué parte cede primero y con qué consecuencia. Un sistema que degrada con gracia —perdiendo cobertura de forma controlada— es infinitamente más valioso que uno que colapsa de forma opaca.
Saber dónde está el límite es la única forma de diseñar la respuesta correcta antes de que el límite te encuentre a ti.