¿En línea o asíncrono? Cómo elegir la forma de integrar sus sistemas

Imagine un jueves de cierre de mes. Su área de operaciones sube un archivo con 50,000 endosos para ajustar la tarifa de la cartera. El portal los recibe y los manda, tan rápido como puede, al sistema central. A los pocos minutos el core empieza a tardar. Después deja de responder. Los agentes que emitían pólizas nuevas en ese mismo momento ven pantallas congeladas, y nadie sabe cuáles de los 50,000 endosos quedaron aplicados y cuáles no.

Nadie se equivocó en el código: se eligió, sin decirlo, una sola forma de integrar (la llamada en línea) para un trabajo que pedía otra. Este artículo es para quien responde por la operación o la tecnología en una empresa regulada o de retail: son tres preguntas, en orden.

Integrar no es «conectar sistemas». Es decidir cómo se comporta el negocio cuando uno de ellos tarda, se cae o recibe diez veces más trabajo de lo habitual.

Primera pregunta: ¿necesita la respuesta en ese instante, o puede esperar?

Hágala por proceso, no por empresa.

• En línea (síncrono): quien pide se queda esperando la respuesta para poder seguir. Una cotización en pantalla: la persona no puede avanzar sin el precio. Es una llamada telefónica.
• Asíncrono: quien pide deja el trabajo, recibe un acuse y sigue con lo suyo; el otro sistema termina a su ritmo y avisa. Una emisión de póliza o un timbrado de factura: lo importante es que se haga bien y que se sepa en qué estado va, no que ocurra en el mismo segundo. Es un trámite en ventanilla.

Cuatro criterios:

1. ¿Hay una persona mirando la pantalla, esperando? Si sí, y la respuesta es breve, tienda a lo en línea.
2. ¿El trabajo tarda más que la paciencia de esa persona? Segundos largos, minutos u horas: asíncrono.
3. ¿El otro sistema aguanta el volumen en el peor momento? Si se satura con un pico, una llamada en línea arrastra consigo al canal que depende de él. Asíncrono.
4. ¿Depende de un tercero que puede tardar o fallar? (un banco, la autoridad fiscal, un proveedor). Asíncrono, y con un número de seguimiento.

Regla práctica: lo que decide una pantalla va en línea; lo que mueve dinero, documentos o inventario suele ir asíncrono.

Si es en línea: ¿REST o gRPC?

La decisión es técnica; el criterio, de dirección:

• REST cuando pesa más la compatibilidad con quienes llaman (un socio, una app, un proveedor) o que cualquiera pueda probar y depurar fácil. Es el idioma común de internet: casi toda herramienta lo entiende. También puede tener contratos versionados.
• gRPC cuando un contrato estricto, clientes generados a partir de él, transmisión continua o un rendimiento medido justifican que quienes llaman lo soporten; por eso suele aparecer entre sistemas propios, donde ambos extremos lo hablan.

Pauta frecuente, no regla: REST hacia fuera, gRPC entre sistemas propios. El detalle está en el artículo «REST o gRPC: cuándo conviene cada uno, y por qué su core no habla ninguno» (/blog/rest-o-grpc-cuando-conviene-cada-uno).

Si es asíncrono: ¿qué sabor?

Para esta decisión conviene distinguir seis opciones frecuentes, que se pueden combinar; la literatura de mensajería empresarial (Hohpe y Woolf) y la documentación de los grandes proveedores de nube [1][2] describen muchas más. Ninguna es «la buena»: cada uno resuelve un problema distinto.

Aviso de regreso: «le avisamos con su folio»

Úselo cuando el trabajo tarda segundos o minutos y quien pidió puede recibir avisos. El sistema receptor responde de inmediato «recibido, su folio es el 4821» y se pone a trabajar. Cuando termina, avisa de vuelta con el folio. En lo técnico, el resultado vuelve mediante un callback; si se entrega por HTTP a una dirección registrada, suele llamarse webhook.

El folio es el número de seguimiento que asocia cada respuesta con su solicitud (identificador de correlación [3]). Sin folio, un aviso es un papel sin dueño.

Consulta por estado: «vuelva con su folio y pregunte»

Úselo cuando quien pidió no puede recibir avisos (cortafuegos, aplicación móvil, terceros con restricciones). Usted vuelve con su folio y pregunta «¿ya está?» cada cierto tiempo.

La documentación de Microsoft lo describe así: la respuesta inicial es un «aceptado» (código HTTP 202) que indica dónde consultar, y la consulta devuelve estados como pendiente, en proceso, exitoso o fallido [4]. Funciona donde el aviso no llega, y propone exigir una clave por solicitud para no procesarla dos veces [4].

Cola: la fila de trabajos

Úselo cuando el sistema que recibe tiene un límite de ritmo y quien envía puede producir mucho más. Quien envía deja su trabajo y se retira; quien procesa lo toma a su propio ritmo. Es, sobre todo, un amortiguador: la documentación de Microsoft lo llama Queue-Based Load Leveling y lo describe como un buffer entre quien pide y el servicio, que suaviza cargas intermitentes que podrían hacer fallar al servicio [5]. Para más velocidad se suman operadores sobre la misma fila (Competing Consumers), si los trabajos son independientes [6].

Escenario (cifras ilustrativas, sin cliente). Un portal recibe 50,000 endosos; el core aguanta 20 por minuto. Sin amortiguador, el portal empuja todo de golpe y el core se satura. A 20 por minuto, el tiempo teórico es de unas 42 horas (50,000 ÷ 20 = 2,500 minutos); el real depende de validaciones, reintentos y ventanas operativas. La cola regula la entrada; el folio por lote, el tablero de avance y las alertas se diseñan aparte, y a cambio no hay un core caído en hora pico.

La cola no hace al core más rápido: hace que su límite deje de ser una sorpresa. No conviene si se necesita respuesta inmediata ni si el volumen es bajo y estable [5].

Evento o tópico: el aviso por altavoz

Úselo cuando un mismo hecho debe mover varias cosas a la vez: documentos, aviso al cliente, CRM, fraude. Los anteriores van de uno a uno; el evento, de uno a muchos. En lugar de decirle a un sistema «haga esto», quien vive el hecho lo anuncia: «póliza emitida», «pago aplicado». Todos los suscritos reciben una copia, y quien lo emite no sabe cuántos son. En la literatura de mensajería es la diferencia entre un canal punto a punto (un receptor) y uno de publicación-suscripción (todos los interesados) [7].

Su costo: todo es eventualmente consistente; durante un rato, unos sistemas saben la noticia y otros no. No sirve si se necesita una sola transacción atómica entre emisor y receptores [8].

Flujo de eventos de alto volumen: la cinta que se puede rebobinar

Úselo cuando los eventos son muchísimos, continuos, y importa conservarlos para releerlos. Apache Kafka lo define como capturar eventos en tiempo real, almacenarlos de forma durable para consultarlos después, y procesarlos tanto en el momento como retrospectivamente [9]. La imagen: una cinta de hechos que varios equipos leen a su ritmo, mientras dure el periodo de retención que se configure [9].

Tiene sentido para telemetría, inventario o fraude; no para una orden puntual, pues es maquinaria que alguien debe operar. Según la documentación de cada proveedor, las garantías de entrega, orden, duplicados y reproducción varían por producto y configuración [10][11].

Intercambio por tablas o archivos: cuando el otro sistema no puede recibir nada más

Úselo cuando el sistema destino es un core antiguo que no sabe hablar ninguno de los idiomas anteriores. Un sistema así suele tener cuatro limitantes:

• No expone interfaces para que otros le pidan cosas, y tampoco avisa cuando algo cambia en su interior.
• Solo acepta datos en una zona de intercambio: tablas o archivos acordados, a donde se les deja la información.
• Los procesa a su ritmo, a menudo por lotes, disparando un proceso propio que los toma, los ejecuta y escribe el resultado.
• Aguanta poca carga, y la respuesta llega cuando termina ese proceso, no cuando se le pide.

La zona de intercambio es una ventanilla de formato fijo: ahí se deja cada instrucción con su folio, y el core deja el resultado en el mismo lugar. Su mérito: no se escribe en las tablas internas del core. Su costo: alguien debe vigilar la zona y la respuesta tarda lo que tarde el lote.

Sobre esa zona va una capa anticorrupción: un traductor de los contratos modernos a los campos y ritmos que el core entiende [12]. Así se moderniza por etapas (Strangler Fig) mientras el core sigue operando [13].

Recibido no es procesado

Si se lleva una sola idea de este artículo, que sea ésta: un acuse de recibo no es una confirmación de resultado. Con frecuencia se cree que, porque llegó el acuse, lo enviado quedó resuelto.

Hay tres niveles de respuesta, y conviene saber en cuál está cada proceso suyo:

Solo el tercer nivel dice si la factura existe, el pago llegó o el pedido se cumplirá. Banxico lo ilustra: liquidado significa que el SPEI liquidó y avisó a la institución receptora, y el CEP hace constar el abono en la cuenta beneficiaria [16].

La industria ya separa recibir de procesar. HTTP define el código 202 como «aceptada para procesamiento, pero el procesamiento no se ha completado»; la solicitud podría no ejecutarse nunca y el protocolo no tiene cómo reenviar después el estado [17]. En AS2, el estándar de intercambio de documentos entre empresas, el ejemplo oficial de recibo firmado trae este comentario: «Esto no es garantía de que el mensaje haya sido procesado por completo o entendido por el traductor receptor» [18].

Lo que vimos. En una integración de pedidos entre dos sistemas corporativos que revisamos, de unas ocho llamadas, dos devolvían el identificador del documento creado; las otras seis, solo un acuse. Los errores llegaban por correo del área receptora, unos tres días después. En el mismo lote había más de diez casos idénticos que nadie había visto: solo se descubren los que alguien revisa por casualidad, y el resto es indistinguible de los que salieron bien. Es una medición de un solo caso, no una cifra de industria. Lo más barato que funcionó: comprobar que la referencia que regresa corresponde al registro correcto. En 234 registros, no dio una sola falsa alarma.

Qué pedir, según el sabor:

• En todos: un folio por operación que viaje de ida y vuelta, para asociar cada resultado con su solicitud [3].
• Aviso de regreso: que avise el resultado; un «terminé» sin decir si se aplicó es otro acuse.
• Consulta por estado: un estado claro por folio (pendiente, en proceso, exitoso o fallido) y, si falló, el motivo [4].
• Cola: que los mensajes que fallan queden apartados para revisión, con su origen anotado [15].
• Tablas o archivos: una línea de resultado por cada registro enviado.

Y dos defensas más. Un estado explícito para lo que no ha regresado («sin confirmar desde las 10:40»): lo peor no es el error, es no saber. Y una conciliación periódica que compare lo enviado contra lo confirmado, con alarma para lo que no regresó a tiempo; así el silencio se vuelve una tarea con responsable.

Problema del sector, primera pregunta, sabor

Guía de conversación, no receta: lo normal es combinar sabores.

Los riesgos, en lenguaje de negocio

Un sabor asíncrono no elimina los problemas: los cambia de lugar. Cinco para la mesa.

• «Ya se cobró dos veces». La mayoría de las colas entregan cada mensaje al menos una vez: puede llegar repetido. Microsoft pide que procesarlo varias veces dé el mismo resultado, para evitar «registros duplicados o cobros repetidos» [5]: cada instrucción lleva una clave única y el sistema registra cuáles ya procesó.
• El orden. Cuando varios operadores toman de la misma fila, no hay garantía de que los trabajos terminen en el orden en que entraron [5][6]. Si «cancelar la póliza» llega antes que «emitir la póliza», hay un problema. Defina la llave de orden de su negocio (póliza, pago, siniestro) y respétela donde importa.
• Reintentos sin freno. Un error pasajero merece otro intento; un rechazo funcional («cuenta inexistente») no se arregla repitiéndolo. Lo recomendado es apartarlo a una cola de excepciones y monitorearla [5][6].
• No saber en qué estado va algo. Es el riesgo de la sección anterior; en eventos conviene, además, un identificador que recorra cada operación de punta a punta [8].
• Cada quien ve una versión distinta, por un rato [8]. Decida de antemano quién es el dueño del dato final y cómo se concilia una operación a medias.

El formato de los avisos es un acuerdo que se versiona; CloudEvents exige que source más id sea único por evento, lo que ayuda a detectar reenvíos [14].

Cinco preguntas para su próximo comité

1. ¿Qué decisiones exigen respuesta inmediata y cuáles pueden resolverse con un folio?
2. ¿Cuál es el ritmo máximo que nuestro core sostiene, y qué pasa si llega diez veces ese volumen?
3. ¿Quién es el dueño del estado final de cada operación, y cómo se concilia una que quedó incompleta?
4. ¿Cómo comprobamos que un reintento no duplica un pago, una póliza, un CFDI o un movimiento?
5. De lo que enviamos ayer, ¿qué operaciones tienen confirmación de resultado (aplicada o rechazada) y cuáles solo un acuse de recibo?

Si en dos o más la respuesta es «no sé», ahí puede estar su riesgo.

Por dónde empezar esta semana

Anote sus procesos más importantes (emisión, cobro, timbrado, inventario), qué sistema responde a cada uno y cuánto trabajo por minuto soporta; y si quien lo inicia necesita la respuesta ya o le bastaría un folio. Verá dónde se usa una llamada en línea para un trabajo que pedía una fila.

Después, tome una interfaz y cuente cuántas operaciones enviadas ayer tienen confirmación de resultado, no solo acuse.

Qué hace Hábil

Hábil es una consultora mexicana de ingeniería, fundada en 2006, que trabaja entre los sistemas que ya tiene una empresa y los canales que necesita abrir. Vea la página Unificar su operación y sus canales.

La primera conversación es sin costo: parte de un mapa de sus integraciones actuales y de dónde su operación podría perder dinero, tiempo o evidencia. Escríbanos por WhatsApp.

Las descripciones de servicios de proveedor reflejan su documentación al 6 de octubre de 2026; son atribuciones del proveedor, no mediciones propias.