Una petición hace una pregunta y espera la respuesta. Un evento anuncia un hecho y sigue adelante.
Casi toda decisión de integración se reduce a esa frase — y casi todo entorno difícil de operar es el resultado de ignorarla. Los patrones no son rivales; responden a preguntas distintas. El dolor empieza cuando uno se fuerza a hacer el trabajo del otro.
El patrón no es una preferencia técnica. Es una promesa sobre cómo fallarán juntos dos sistemas.
Elija petición-respuesta cuando quien llama no pueda continuar sin la respuesta. Elija un evento cuando el hecho importe a más consumidores de los que puede nombrar hoy.
Qué promete realmente cada patrón
Una llamada síncrona acopla la disponibilidad
Cuando el sistema A llama al sistema B y espera, A ha heredado en silencio su disponibilidad, su latencia y sus ventanas de mantenimiento. A una llamada de profundidad, no pasa nada. A tres saltos, el sistema más débil de la cadena fija la disponibilidad de todo el recorrido — y nadie aceptó eso.
Un evento desacopla el tiempo
El productor anuncia “empleado contratado”, “pedido creado”, “asiento liberado” — y ha terminado. Los consumidores procesan a su propio ritmo, se pueden añadir sin tocar al productor y pueden reproducir los mensajes al recuperarse. El precio: nadie está esperando, así que nadie sabe al instante si aguas abajo salió bien.
El fallo es donde los patrones se diferencian de verdad
Una llamada fallida falla en voz alta, en la cara de quien llama, en el momento de preguntar — ideal cuando una persona espera la respuesta. Un evento fallido falla en silencio, más tarde, en una cola — ideal cuando la entrega debe sobrevivir a una caída, y peligroso cuando nadie es responsable de vigilar esa cola.
Decidir por las dimensiones que lo determinan
SAP Integration Suite soporta ambos patrones — los flujos de Cloud Integration y las APIs gestionadas por un lado, las capacidades de event mesh por el otro — de modo que la elección puede hacerse por interfaz y no por plataforma.
El entorno necesita ambos — deliberadamente
Los entornos reales son mixtos: quien consulta los datos bancarios de un empleado necesita una respuesta síncrona; la contratación que creó a ese empleado debería haber sido un evento, porque a la nómina, al aprovisionamiento de TI, a la gestión de accesos y a la analítica les importa a todos, y ninguno debería retener la transacción de contratación.
El indicador de alarma es la uniformidad. Un entorno donde todo es una llamada API punto a punto suele haber recreado el mismo enredo que pretendía sustituir — con mejores registros. Un entorno donde todo es un evento suele haber descubierto que algunas preguntas sí necesitaban respuesta.
Nombrar la interacción→¿Pregunta o hecho?→Elegir el contrato→Diseñar primero la ruta de fallo
Reglas que sobreviven al contacto con producción
- Decida por interacción, no por proyecto. Un solo proceso suele contener tanto una pregunta como varios hechos.
- Haga idempotente a cada consumidor. Reintentos y reproducciones son una característica de la integración resiliente, no una anomalía — procesar dos veces el mismo mensaje debe ser seguro.
- Dé a cada cola un responsable. Una cola de mensajes fallidos sin supervisión es una caída con temporizador.
- Versione el contrato, no la lista de consumidores. El sentido de un evento es que el consumidor de mañana no le cueste nada al productor.
Perspectiva de VISCAP
La deuda de integración es deuda de disponibilidad. Cada salto síncrono que añade hoy es una caída que avala para más adelante.
Cuando revisamos un entorno, leemos la lista de interfaces contra una sola pregunta: quién está esperando a quién, y ¿lo decidió alguien a propósito? El mapa de las esperas accidentales — procesos por lotes bloqueados en llamadas en vivo, interfaces bloqueadas en cadenas de servicios — suele ser la vía más rápida hacia la estabilidad y la velocidad a la vez.
La pregunta que hacerle a cada nueva interfaz
No “¿API o evento?” en primer lugar — sino “si el otro lado se cae durante una hora, ¿qué debería pasar aquí?” Responda con honestidad y el patrón suele elegirse solo.