Las organizaciones con decenas de sistemas suelen enfrentarse a una maraña de conexiones punto a punto: cada sistema se comunica directamente con varios otros, cada uno con su propio protocolo y contrato. El resultado es que cambiar un sistema rompe varios más, y añadir un nuevo canal, como una aplicación móvil, exige meses de trabajo de integración. Cuando un equipo quiere saber cuál fue la última transacción de un cliente, tiene que consultar tres sistemas y combinar las respuestas a mano. En la práctica, la capa de integración está repartida de forma invisible entre todos los sistemas y no pertenece a nadie.
Esto importa porque la velocidad de la transformación digital de una organización está directamente ligada a la velocidad de su integración. Si cada nuevo producto exige volver a conectarse a los sistemas centrales, el coste de probar nuevas ideas se vuelve prohibitivo. Cada conexión directa es, además, un punto de seguridad sin supervisión: ¿quién llama, con qué autorización y con qué frecuencia? Sin una capa compartida, esas preguntas se responden por separado para cada conexión, lo que en la práctica significa que nadie tiene la respuesta completa.
La arquitectura preferida combina dos patrones complementarios. La pasarela de API es el punto de entrada único para las interacciones síncronas: un consumidor envía una solicitud y recibe una respuesta en el mismo momento. La pasarela aplica de manera uniforme la autenticación, la autorización, la limitación de tasa, el versionado y la observabilidad. La arquitectura orientada a eventos sirve a las interacciones asíncronas: cuando ocurre algo, como la apertura de una cuenta o un cambio de dirección, el sistema de origen publica un evento y cualquier sistema interesado lo consume, sin que el origen tenga que saber quiénes son los consumidores. Una cola de mensajes persistente entre ambos garantiza que no se pierda ningún evento.
La primera consideración práctica es el diseño de contratos. Las API y los eventos son contratos y deben tratarse como tales: con un esquema explícito, un versionado explícito y una regla clara que distinga los cambios compatibles de los que rompen la compatibilidad. Por ejemplo, añadir un campo opcional a un evento de «cliente actualizado» es un cambio compatible, pero cambiar el tipo de un campo existente exige una nueva versión publicada junto a la anterior durante un periodo de transición. Un registro central de esquemas permite a los equipos comprobar la compatibilidad automáticamente antes del despliegue, en lugar de descubrir una rotura en producción.
La segunda consideración es elegir correctamente entre lo síncrono y lo asíncrono. La regla práctica: si el consumidor necesita la respuesta de inmediato para continuar con su trabajo, utilice una API; si solo necesita saber que algo ha ocurrido, utilice un evento. Una consulta de saldo es síncrona. Notificar una transacción al sistema de prevención del blanqueo de capitales es asíncrono. Muchos problemas de rendimiento y acoplamiento en las organizaciones proceden de interacciones asíncronas implementadas como llamadas síncronas, en las que un sistema lento ralentiza toda la cadena.
La tercera consideración es la observabilidad de extremo a extremo. Cuando una solicitud entra por la pasarela, atraviesa varios servicios y genera varios eventos, el equipo debe poder seguir todo el recorrido con un único identificador de correlación. Ese identificador debe viajar tanto en las cabeceras de la API como en los metadatos de los eventos. Sin él, depurar un problema se convierte en cotejar a mano marcas de tiempo en los registros de varios sistemas, algo prácticamente imposible en horas punta.
Los errores habituales se agrupan en unas pocas categorías. Primero, convertir la pasarela de API en el lugar de la lógica de negocio; la pasarela debe aplicar políticas, no tomar decisiones de negocio. Segundo, los eventos «gruesos», que transportan el registro completo y atan a los consumidores a la estructura interna del origen, o los eventos «delgados», que solo llevan un identificador y obligan a todos a volver a consultar. Tercero, ignorar el orden y la duplicación; un consumidor debe poder reconocer un evento repetido y gestionar uno que llegue desordenado. Cuarto, no tener un responsable de la capa de integración, lo que la devuelve discretamente a la situación anterior.
En Niadad, esta tríada se implementa como tres plataformas complementarias. Sepehr es la pasarela de API empresarial: autenticación, autorización, limitación de tasa, versionado y observabilidad para todas las interacciones síncronas. Jarian es la plataforma de eventos: publicación, suscripción y esquemas de eventos con historial conservado. Payam es la cola de mensajes persistente que garantiza la entrega y la gestión de errores en el trabajo asíncrono. En el programa bancario de Niadad, las tres forman la columna vertebral de la integración y se conectan con las capas de identidad, partes y datos.
Una pasarela de API y una arquitectura orientada a eventos son dos respuestas a dos preguntas distintas, y una organización madura cuenta con ambas. Lo que las convierte en una única infraestructura son los contratos explícitos, la identidad compartida y la observabilidad de extremo a extremo. Con estos tres elementos, añadir un nuevo canal o sistema deja de ser un proyecto de varios meses para convertirse en cuestión de días. Esa es la verdadera medida de una capa de integración: no lo elegante que resulte su diagrama, sino lo poco que obstaculiza el siguiente cambio.