La integración es donde la entrega se vuelve real.
Cualquiera puede llamar una API en un demo. Producción es lo que pasa cuando el otro sistema está lento, equivocado, o desaparecido un momento.
El problema
La mayor parte del trabajo genuinamente difícil en el software moderno no es construir una funcionalidad. Es hacer que dos sistemas que se diseñaron por separado estén de acuerdo sobre el mismo hecho, de forma continua, mientras los dos siguen cambiando.
Ese trabajo es donde los proyectos de verdad fallan. Un pago que se registró dos veces. Un conteo de inventario que se desvió. Un webhook que llegó fuera de orden a las 2 de la mañana y nadie lo notó por una semana.
Tratamos la integración como un problema de ingeniería de primera clase, con sus propios modos de falla: idempotencia, reintentos con espera creciente, reconciliación, y alertas que dicen la verdad. Cada integración se entrega con una forma de detectar y reparar la desviación, porque toda integración eventualmente se desvía.
- Operaciones idempotentes, para que un reintento no pueda cobrar ni registrar dos veces
- Procesos de reconciliación que detectan la desviación en vez de esperar a que la encuentre un cliente
- Manejo de eventos ordenado y repetible, no webhooks que se lanzan y se olvidan
- Alertas sobre el hecho de negocio, no solo sobre el código HTTP
Qué cubre esto
Integración de APIs
Pagos, ERP, historia clínica, logística, identidad, y la larga cola de sistemas internos.
Pipelines de datos
Mover y transformar datos con el linaje para comprobar qué pasó.
Reconciliación
Detección automática de desviación entre sistemas que tienen que estar de acuerdo.
Diseño para la falla
Reintentos, espera creciente, manejo de mensajes muertos y llaves de idempotencia.
Comportamiento bajo carga
Verificado contra el volumen y el patrón de picos que de verdad tienes.
Secretos y accesos
Manejo de credenciales que sobrevive una auditoría.
La otra mitad: sacar respuestas
Mover los datos correctamente es el primer trabajo. El segundo es que alguien en tu negocio quiere un número, y hoy o le pregunta a alguien de ingeniería o le cree a una hoja de cálculo que está equivocada desde marzo.
Construimos la capa de reportes como parte del producto y no como un proyecto que arranca después. Eso significa una bodega o un almacén de reportes alimentado por los mismos pipelines, métricas definidas una sola vez para que dos tableros no puedan contradecirse, y linaje que puedes seguir hacia atrás cuando una cifra se ve mal. La definición de la métrica es el entregable. La gráfica es la parte fácil.
Cuando la pregunta es genuinamente exploratoria te lo decimos, y preferimos conectar la herramienta que ya tienes a un modelo limpio que venderte la construcción de un tablero que no necesitabas.
- Un almacén de reportes alimentado por los mismos pipelines, para que los datos operativos y los analíticos no se separen
- Definiciones de métricas escritas una vez y compartidas, para que dos tableros no puedan discrepar sobre los ingresos
- Linaje desde el número en pantalla hasta la fila que lo produjo
- Seguimiento de eventos diseñado junto con el producto, porque la analítica puesta después mide las cosas equivocadas
- Tu herramienta de BI actual conectada a un modelo limpio, cuando esa es la respuesta más barata
La experiencia de Koombea en integraciones con otros sistemas y APIs nos ha dado el conocimiento necesario para resolver muchos problemas de integración, algo que ha sido crítico para nuestro éxito.
Qué mueve la estimación
El trabajo de integración es donde se pone a prueba el precio fijo, porque la mitad del costo vive en el sistema de la otra parte y nada de eso se ve en una lista de funcionalidades. Lo dimensionamos por los modos de falla y no por la cantidad de endpoints.
El factor más grande es si el sistema aliado se comporta bien. Una API documentada, versionada e idempotente con ambiente de pruebas cuesta una fracción de lo que cuesta un endpoint SOAP sin documentar que devuelve HTTP 200 con un error dentro del cuerpo.
- Si existe un ambiente de pruebas, porque probar contra producción es un costo y un riesgo
- Cómo se comporta el aliado cuando falla: si un reintento duplica, y si te puedes dar cuenta
- Si los eventos llegan ordenados, y qué hay que hacer cuando no
- Volumen y patrón de picos, que deciden si se necesitan colas y control de flujo
- Si los dos sistemas tienen que estar de acuerdo de forma continua o pueden reconciliar en la noche, que es una decisión de arquitectura y no una preferencia
Las capas de abajo
Colas y caché
Redis para caché y colas, con procesos en segundo plano dimensionados por el patrón de picos y no por el promedio.
Observabilidad
Datadog para monitoreo de aplicación e infraestructura, CloudWatch donde la carga es nativa de AWS.
Secretos y accesos
Un almacén de secretos administrado con acceso de mínimo privilegio, escogido contra tu ambiente y no contra el nuestro.
Pruebas de contrato
Pruebas que fallan cuando un aliado cambia su formato, antes de que se enteren tus clientes.
Seguridad en el pipeline
Escaneo de dependencias, análisis estático y dinámico corriendo como puertas de calidad y no como una revisión anual.
Infraestructura como código
Terraform y Docker donde el proyecto incluye aprovisionamiento, para que un ambiente sea reproducible.
Preguntas que vale la pena hacer
El sistema con el que necesitamos integrarnos no tiene documentación. ¿Ahora qué?
¿Quién responde cuando la API del aliado cambia y algo se rompe?
¿La reconciliación la construyen ustedes o nosotros?
¿Pueden trabajar con nuestro equipo de datos y no alrededor de él?
Ya tenemos una herramienta de BI que nadie usa. ¿Ese es un problema de datos?
Cuatro sistemas, una tienda reconciliada
La tienda de Jamar integra precios, inventario, pagos y datos de producto a través de STEP, con segmentación de precios por ubicación para un modelo de precios regional.
Tráenos el backlog.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.