TL;DR

  • “Integración” nombra dos problemas distintos: exponer capacidades para que apps las consuman (requests) y mover datos hacia una plataforma analítica (datasets). Una regla escrita para el primero se convierte en muro para el segundo.
  • API-led: System, Process y Experience son responsabilidades, no pasos obligatorios. pipeline -> System API -> origen es API-led válido sin Process ni Experience de relleno.
  • El desacoplamiento no es gratis: cambias una dependencia por una cadena de dependencias, y el throughput de la API, no tu infraestructura, decide si cumples la ventana de carga.
  • Antes de aceptar o rechazar la capa de integración en tu ingesta, pregunta por los NFRs: 50 millones de registros a 500 registros por segundo son cerca de 28 horas.
  • La salida no es pelear la frontera ni pedir excepciones: es nombrar una tercera categoría, ingesta por API con frontera gobernada, y dejarla firmada en un ADR.

Dos mundos que comparten una palabra

En muchas organizaciones conviven dos capacidades que casi nunca se saludan: una capa de integración que expone APIs corporativas, y una plataforma de datos que ingiere de todo lo que respira. Tarde o temprano, en una revisión de arquitectura llega la pregunta:

Si tu capa de ingesta consume APIs externas, ¿por qué no pasa por la capa de integración?

La pregunta suena técnica, pero el problema es de vocabulario. Cuando el equipo de integración dice “integración”, piensa en exponer capacidades para que una aplicación las consuma: request, respuesta, contrato, milisegundos. Cuando el equipo de datos dice “integración”, piensa en traer datos a un repositorio: volumen, ventana nocturna, millones de registros.

Son dos unidades de trabajo distintas. El mundo transaccional mide en requests: un clic, un usuario, una respuesta inmediata. El mundo analítico mide en datasets: una tabla completa, un histórico de años, un lote nocturno.

La distinción se ve trivial hasta que la pones en términos de carga:

Capa de integración:   "necesito el saldo de este cliente AHORA"
Plataforma de datos:   "necesito millones de transacciones para analizar"

Dos flujos legítimos, dos patrones de tráfico distintos, una sola palabra para ambos. Ahí empieza el conflicto, y ninguna de las dos partes está equivocada.

Las visualizaciones interactivas se ven mejor en pantalla grande (PC/laptop). En móvil puedes interactuar, pero el espacio es limitado.

API-led sin misterio

El modelo que suele estar detrás de la capa de integración se llama API-led connectivity. “Led” como en data-driven o event-driven: guiado por. La conectividad se organiza alrededor de APIs reutilizables en lugar de conexiones punto a punto entre cada consumidor y cada sistema.

La analogía del restaurante lo hace clic: el cliente no entra a la cocina. Habla con el mesero, el mesero coordina con la cocina, y alguien más va por los ingredientes. Nadie cocina de todo ni todos cargan cajas.

En el modelo, tres responsabilidades:

  • System API: “yo sé hablar con este sistema”. Esconde las peculiaridades del backend: OAuth, endpoints raros, campos con nombres horribles, versiones. El consumidor solo pide GET /customers/123.
  • Process API: “yo resuelvo una capacidad de negocio”. Un Customer 360 que combina el sistema comercial, el financiero y el MDM en una respuesta coherente.
  • Experience API: “yo adapto la capacidad al canal”. El punto de venta, la app móvil y el call center necesitan la misma información con formas distintas.

Y aquí viene lo que casi nadie te dice: esas tres capas no son un pipeline obligatorio. No son paso 1, paso 2, paso 3. Una integración puede ser perfectamente pipeline -> System API -> origen, sin Process ni Experience, y no por eso deja de ser API-led. Crear capas solo para “estar haciendo API-led” es burocracia con diagrama bonito.

¿Cuándo sí ganan su lugar las tres? Cuando el flujo lo pide. Un MDM que produce el Golden Record y lo sirve a un POS, una app y un call center encaja natural: System para acceder al Golden Record, Process para combinarlo con crédito y lealtad, Experience para adaptarlo por canal. Eso es integración operacional de manual. Pedir lo mismo para un análisis que recorre 30 millones de clientes es forzar el patrón: ahí el camino natural es bulk, CDC o export.

Desacoplamiento no es gratis

¿Por qué alguien querría que hasta la ingesta pase por la capa de integración? Por razones buenas. Esa capa centraliza autenticación, autorización, rate limits, auditoría, versionado, monitoreo, y sobre todo abstracción: hoy el contrato habla de Salesforce, mañana el backend cambia de nombre y el consumidor ni se entera.

Para una app, ese valor es enorme. Para una plataforma de datos, también tiene valor real: tu pipeline conoce un contrato corporativo estable, no las peculiaridades de cada origen. No hay que negarlo, hay que costearlo.

Porque el desacoplamiento no elimina la dependencia: la reubica y le pone dueño.

Directo:
  origen -> pipeline -> repositorio
  (una dependencia: el origen)

Con capa de integración:
  origen -> capa de integración -> pipeline -> repositorio
  (origen disponible + capa disponible + API disponible + capacidad suficiente)

Cada capa nueva que metes en el data path es una cosa más que puede fallar, con su propio SLA, su propio equipo y su propia ventana de mantenimiento. Puede valer la pena, pero es una decisión de costo, no un reflejo.

Los NFRs deciden, no el diagrama

Hay una distinción que cambia toda esta conversación: una API puede ser funcionalmente correcta y operacionalmente inadecuada para tu workload.

Piénsalo con números. Necesitas 50 millones de registros y el camino efectivo te da 500 registros por segundo:

50,000,000 / 500 = 100,000 segundos ≈ 28 horas

La API funciona perfecto. Tu ventana de carga es de horas. La solución no cumple, sin que nadie haya hecho nada mal.

El throttling complica el cuadro. Tu pipeline puede paralelizar con 50 workers y generar 3,000 peticiones por segundo. Si la capa de integración acepta 200, el resto regresa en HTTP 429, con reintentos y backoff. Tu infraestructura escalable queda esperando detrás de un caño angosto.

Y ojo: puede que la capa esté haciendo exactamente su trabajo. Limitar 200 peticiones por segundo para proteger el origen de consumidores voraces es razonable. El problema no es que la regla sea mala, es que fue diseñada para otro workload.

La pregunta correcta tampoco es “¿qué herramienta uso?”, sino “¿qué patrón requiere este flujo?”:

  • Request/response: integración operacional. Un cliente, una orden, una respuesta inmediata.
  • Eventos: integración por streaming. El cambio ocurre y alguien más reacciona.
  • Bulk/CDC: movimiento de datos. Volumen, históricos, captura incremental.

“Tenemos una capa de integración, así que todo dato debe atravesarla” es tan fuerte como “somos la plataforma de datos, así que nunca pasamos por ella”. La herramienta se elige después del patrón, no antes.

Y cuando el flujo sí cruce la frontera, las preguntas que debes llevar a la mesa son concretas: ¿la API fue diseñada para consumo operacional o para extracción masiva? ¿Qué throughput soporta y qué throttling aplica? ¿Tiene endpoints bulk o interfaces CDC? ¿Qué SLA tiene, qué latencia agrega, cómo pagina millones de registros? ¿Quién paga esa capacidad y quién contesta el teléfono cuando falla?

La dimensión que casi nadie discute: la organización

Cuando estas discusiones se atascan, casi nunca es por la técnica. Vale la pena mirar cómo nacen las reglas corporativas.

Primero: muchas reglas no se diseñan, se acumulan. Nacen de colisiones, respuesta por respuesta, en proyectos grandes donde cada equipo se topa con el siguiente. Una regla que nace de colisiones hereda la forma de las colisiones, no la del territorio que gobierna.

Segundo: la letra y la intención divergen. “Toda API externa pasa por la capa de integración” se escribió imaginando un consumidor concreto: una persona abriendo una app. Las justificaciones habituales, OAuth, contratos, auditoría, son controles sobre quién accede y cómo. Ninguna dice nada sobre cuánto mueve. Un pipeline que extrae volumen de una API externa cumple la letra de la regla, pero no vive en la imaginación que la escribió.

Tercero: las reglas suelen tener más matices de los que recuerdas. Es común que el estándar ya traiga una excepción de fábrica: las bases de datos no pasan por la capa de integración. Eso clasifica por tipo de interfaz (APIs sí, bases de datos no), no por tipo de trabajo. Y demuestra algo útil: la organización ya acepta acceso directo cuando el patrón no le queda al estándar. El precedente que necesitas puede ya vivir dentro de la regla que te frena.

Cuarto, y más simple: el nombre de tu capa decide la conversación. Si tu diagrama dice “Integration Layer”, el equipo de integraciones leerá su capacidad empresarial y preguntará dónde está su herramienta. Si dice “Data Ingestion”, dice otra cosa: aquí ocurre la adquisición y el movimiento de datos. El conflicto puede nacer de una etiqueta antes de nacer de la arquitectura.

Y el hallazgo de fondo suele ser incómodo: ambos lados tienen sus estándares escritos. Los patrones de ingesta están documentados de un lado; la regla de APIs del otro. No faltó documentación. Faltó interoperabilidad entre documentaciones: dos marcos correctos que jamás se leyeron entre sí.

Cómo se cierra: patrón primero, ADR después

Ante una regla que no te contempla, hay dos caminos, y uno está mal.

El camino fácil es pedir excepciones. Una excepción es una extensión eléctrica: funciona, hasta que quema algo. Y si el acuerdo dice “si los NFRs no se cumplen, nos conectamos directo”, acabas de matar el incentivo para que alguien mejore la capacidad. La puerta de salida siempre disponible jamás se arregla.

El camino serio es expandir la regla con una categoría nueva. En términos de carga eléctrica: el enchufe de casa es para aparatos pequeños y funciona bien. Un pipeline es una máquina industrial, y una máquina industrial no falla en el enchufe doméstico porque el enchufe esté mal, sino porque la carga es otra. La solución no es colarse por el enchufe de casa, es instalar un circuito trifásico: misma red, mismo medidor, mismo estándar, clasificado por carga.

Pero pedir el trifásico de gratis no funciona. El miedo fundacional del equipo de integraciones es el punto a punto salvaje: cada equipo conectándose a cada sistema sin control, sin visibilidad, sin contrato. Si llegas a pedir orquestar tu ingesta sin ofrecer nada a cambio, les estás pidiendo que aprueben por escrito el desorden que existen para evitar.

El trueque honesto: a cambio de orquestar, tu lado ofrece un menú nombrado de patrones. Ingesta por CDC cuando el origen lo soporta, snapshot o bulk para históricos, streaming cuando hay eventos. Cada uno con dueño, credenciales, monitoreo y documentación. No “confía en nosotros”: “estos son los patrones con los que operamos y ningún otro pasa”.

Y el documento donde todo esto aterriza es un ADR, Architecture Decision Record: contexto, opciones consideradas, decisión, consecuencias. Su valor no es el papel, es que la línea deja de vivir en la memoria de una conversación y pasa a ser memoria institucional. Sin ADR, tu acuerdo es tan frágil como la regla original que nació de colisiones: el siguiente proyecto vuelve a chocar contra la misma pared.

La frase que yo llevaría a ese documento:

Para la ingesta desde APIs externas, la frontera gobernada sigue siendo la capa de integración: no hay conexión punto a punto al origen. La orquestación y las herramientas son las estandarizadas del equipo de datos, conectándose a través de esa frontera, con visibilidad y contrato. Aplica siempre que la interfaz cumpla con los requisitos del workload: volumen, tiempo y latencia. Si la interfaz no los cumple, la primera respuesta es que el dueño de la frontera mejore su capacidad en un plazo definido; si no puede, existe una vía directa nombrada y gobernada, igual que la que ya existe para bases de datos.

Fíjate que en una sola frase conviven los valores de los dos mundos: visibilidad y contrato, del lado de integración; volumen y latencia, del lado de datos. El documento no es una tregua, es una traducción. Y no tiene ninguna caja “sin gobierno”: tiene puertas gobernadas distintas.

Dudas que valen mantener abiertas

  • El texto del estándar casi nadie lo ha leído completo. Sus sustantivos, si dice “app”, si dice “consumidor”, si menciona datos, deciden si tu caso está dentro del alcance o nunca fue imaginado.
  • La intención de la regla rara vez la explica quien la escribió. Mientras tanto, todos operan con su hipótesis más generosa.
  • Los NFRs reales de la API corporativa suelen ser desconocidos: throughput, throttling, SLA, paginación para millones de registros.
  • Y la pregunta que cierra cualquier negociación seria: cuando la frontera falle a las 2 AM, ¿quién contesta el teléfono?

Cierre

No peleo la frontera. Peleo el enchufe.

Que un dato sea accesible por API no significa que su movimiento sea un problema de integración operacional, y que un workload pertenezca a la plataforma de datos no significa que deba saltarse las APIs corporativas. Se decide flujo por flujo, según el patrón de acceso, el contrato y los NFRs.

La regla que nunca te imaginó no está mal. Está incompleta. Y tu trabajo no es rogarle una excepción: es ponerle nombre a la categoría que falta y dejarla por escrito.

Fuentes