Integraciones B2B: cómo medir y controlar la latencia extremo a extremo antes de que el SLA te explote
Integraciones B2B: cómo medir y controlar la latencia extremo a extremo antes de que el SLA te explote
El SLA firmado dice "tiempo de respuesta inferior a 2 segundos". Tu dashboard interno marca 1,8 segundos. El cliente llama el lunes para decir que sus analistas llevan una hora esperando datos frescos. Alguien mide mal, y casi nunca es el cliente.
El problema no es la latencia del endpoint. Es que nadie midió la latencia de punta a punta: desde que el evento ocurre en la fuente hasta que el dato enriquecido aterriza en el sistema de destino. Cada integración B2B añade capas —autenticación, colas, transformaciones, reintento, normalización— que el SLA de la API upstream nunca contempla.
Si tu equipo diseña integraciones sobre APIs de datos del universo público, este es el agujero más frecuente y el más silencioso.
El error de confundir latencia de API con latencia de integración
Una API puede responder en 300 ms. Tu integración puede tardar 40 minutos en hacer llegar ese dato al sistema que lo necesita.
La diferencia la crean:
- Polling intervals mal calibrados (cada 5 minutos cuando el negocio necesita cada 30 segundos).
- Colas intermedias que se saturan bajo carga punta sin alarma.
- Transformaciones síncronas que bloquean el hilo antes de escribir en destino.
- Reintentos con backoff exponencial que acumulan deuda temporal silenciosa.
- Pipelines de enriquecimiento encadenados que multiplican la latencia por cada paso.
Medir solo el tiempo de respuesta HTTP es medir la capa más rápida del sistema. Es como medir la velocidad de un tren por la aceleración inicial.
Cómo instrumentar la latencia real extremo a extremo
El primer paso es añadir un timestamp de evento de origen en cada registro que entra al pipeline. No el timestamp de la llamada API, sino el momento en que la señal ocurrió en la fuente pública.
Con ese dato, puedes calcular dos métricas que importan de verdad:
- Lag de ingestión: tiempo entre el evento en la fuente y la primera vez que el dato entra al pipeline.
- Lag de disponibilidad: tiempo entre el evento en la fuente y el momento en que el sistema de destino puede consultar el dato.
import time
def ingest_record(record: dict) -> dict:
record["_pipeline_ingested_at"] = time.time()
# El campo "published_at" viene de la fuente pública
source_ts = record.get("published_at")
if source_ts:
record["_ingest_lag_seconds"] = record["_pipeline_ingested_at"] - source_ts
return record
Ese campo _ingest_lag_seconds es lo que tienes que enviar a tu sistema de métricas, no el tiempo de respuesta HTTP. Con histogramas de percentiles (p50, p95, p99) sobre este valor obtienes una imagen honesta del comportamiento del pipeline bajo carga real.
Los tres cuellos de botella que nadie revisa hasta que ya es tarde
1. El buffer de cola sin límite de antigüedad
La mayoría de las implementaciones con Kafka, RabbitMQ o SQS configuran el tamaño máximo de la cola pero no el tiempo máximo de retención por mensaje. Un mensaje que lleva 90 minutos en cola puede procesar correctamente y aun así llegar fuera del SLA. Añade message_ttl o su equivalente y genera una alarma cuando expire más del 1 % de los mensajes.
2. El enriquecimiento síncrono acoplado
Si tu pipeline enriquece cada señal llamando a una API secundaria de forma síncrona —geolocalización, clasificación temática, resolución de entidades— estás multiplicando la latencia por el número de llamadas. Desacopla el enriquecimiento a una etapa asíncrona posterior. El dato base llega rápido; el dato enriquecido llega después. Decide qué necesita cada consumidor downstream antes de asumir que todos necesitan todo.
3. El retry loop que esconde la degradación
Un endpoint que empieza a tardar 2 segundos en lugar de 300 ms no lanza una alarma inmediata si el cliente HTTP tiene timeout a 5 segundos. El pipeline sigue funcionando, los datos siguen llegando, pero el lag crece 6x sin que nadie lo vea. Monitoriza el tiempo de respuesta upstream como métrica independiente, con alertas de degradación gradual, no solo de error.
Qué negociar con el proveedor de datos upstream
El SLA de disponibilidad que firma el proveedor (99,9 % uptime) no equivale a un SLA de latencia de señal. Son contratos distintos. Antes de firmar, exige por escrito:
- Latencia máxima de indexación: tiempo entre que el contenido aparece en la fuente pública y está disponible en la API.
- Frecuencia de actualización del índice: cada cuánto tiempo el sistema upstream ingiere señales nuevas.
- Comportamiento bajo carga punta: qué ocurre con la latencia cuando el volumen de señales se multiplica por un evento excepcional (elecciones, crisis de mercado, lanzamiento masivo).
Si el proveedor no puede responder estas tres preguntas con cifras medibles, el SLA de tu integración es una estimación sin base real.
En plataformas como FeedScale, orientadas a Text and Data Mining sobre el universo público, estas métricas forman parte de las capacidades documentadas de la API — no son preguntas incómodas, son parámetros de diseño.
Un modelo de alerta pragmático para equipos pequeños
No necesitas un stack de observabilidad complejo para empezar. Con tres alertas cubro el 80 % de los problemas de latencia en integraciones B2B de datos:
| Alerta | Condición | Acción |
|---|---|---|
| Lag de ingestión alto | p95 > umbral_negociado × 1,5 | Investigar upstream y colas |
| Mensajes expirados en cola | Tasa de expiración > 1 % | Revisar capacidad de consumo |
| Tiempo respuesta upstream | p99 > 2 × baseline | Activar modo degradado / caché |
El "modo degradado" es clave: define qué hace el sistema cuando los datos llegan tarde. ¿Sirve el último dato disponible con etiqueta de antigüedad? ¿Bloquea? ¿Notifica al consumidor? Esa decisión debe estar en el diseño, no en el momento del incidente.
La latencia es una propiedad del sistema, no de la API
El error más caro en integraciones B2B con APIs de datos no es técnico. Es de framing: asumir que la latencia es responsabilidad del proveedor upstream y que tu pipeline es un conductor neutro.
Tu pipeline transforma, almacena, enriquece, reintenta y encola. Cada una de esas operaciones tiene coste temporal. Ese coste es tuyo.
Mídelo desde el primer día. Negocia SLAs con el dato real en la mano. Y diseña el modo degradado antes de necesitarlo, porque lo vas a necesitar.