«Lo necesitamos en tiempo real» parece un requisito claro hasta que alguien pregunta cuánto tiempo, exactamente, puede pasar entre una venta y su aparición en el sistema de operaciones. ¿Segundos? ¿Diez minutos? ¿Basta con que esté antes de preparar los envíos? La respuesta cambia bastante la arquitectura, y a menudo cuesta más acordarla que conectar las aplicaciones.
Si estás eligiendo entre eventos y procesos programados, empieza por ahí. Consultar el CRM cada diez minutos y recibir una notificación cuando se confirma una venta pueden resolver necesidades distintas con resultados igualmente válidos. La elección se vuelve interesante al mirar lo que sucede después: cómo sabes que el trabajo terminó, qué haces si falta una notificación y cómo evitas que un reintento duplique el pedido.
Qué te está diciendo un evento
Un evento describe un hecho: un pedido confirmado, un documento recibido o una solicitud cerrada. Los consumidores reaccionan a ese hecho según sus propias responsabilidades. Un proceso programado, en cambio, se ejecuta siguiendo un calendario y consulta qué trabajo está disponible. La arquitectura basada en eventos descrita por Microsoft separa productores, canales y consumidores. Esa separación permite diseñar componentes independientes, pero obliga a tratar explícitamente la entrega y el procesamiento.
Un webhook es una forma de notificación mediante una petición entre sistemas. No garantiza por sí solo conservación, reintentos ni procesamiento correcto. Esas propiedades dependen del contrato del proveedor y de la arquitectura receptora.
Pregunta cuánto retraso es aceptable y qué sucede si se supera. “En tiempo real” suele expresar una expectativa, pero no define un objetivo operativo. Conviene convertirla en un plazo medible desde el hecho de origen hasta el resultado. Si una actualización puede esperar horas, un lote programado puede ser más sencillo. Si el valor disminuye con cada minuto, una notificación puede reducir espera. Aun así, hay que considerar el tiempo de los consumidores y sus dependencias.
Compara también el volumen de consultas vacías. Un sondeo muy frecuente puede consumir recursos aunque no haya novedades. La comparación debe incluir ese coste y la complejidad de mantener un canal de eventos fiable.
Recibir el mensaje es solo el principio
Al recibir una notificación, valida autenticidad, formato y tamaño. Después decide cuándo confirmas su recepción. Si respondes antes de conservar el trabajo de forma duradera, una caída puede provocar pérdida de información.
Si procesas todo antes de responder, una operación lenta puede agotar el tiempo de espera del emisor. Una opción habitual es registrar la entrada de forma segura, confirmar recepción y procesar después, con visibilidad del estado. Esa decisión necesita un contrato claro. El emisor debe entender si la respuesta significa “recibido” o “completado”. Confundir ambos estados genera incidencias difíciles de detectar desde el punto de vista del cliente.
El mensaje puede llegar dos veces, o fuera de orden
Muchos sistemas pueden entregar un mensaje más de una vez. El consumidor debe comprobar si el identificador de evento o la operación de negocio ya fueron procesados. Esto resulta especialmente importante cuando crea pedidos o envía comunicaciones. El orden tampoco debería suponerse globalmente. Una actualización posterior puede llegar antes que otra anterior. Incluye referencias de versión cuando el origen las permita y define cómo descartar cambios obsoletos o recuperar el estado vigente.
Evita prometer ejecución única de extremo a extremo sin verificar todas las dependencias. Un control de duplicados en la entrada no impide por sí solo que una llamada externa incierta se repita.
Tres equipos y un pedido a medio camino
Imaginemos una venta que debe llegar a operaciones, facturación y seguimiento comercial. El productor registra el pedido y emite un evento identificable; cada consumidor realiza su parte sin esperar a que todos terminen a la vez. Hasta ahí, el esquema resulta atractivo. La dificultad aparece cuando operaciones ya ha reservado trabajo y facturación lleva veinte minutos sin responder.
Repetir todo el recorrido sería una mala recuperación si vuelve a reservar lo que ya estaba reservado. En este diseño hipotético, la etapa de facturación permanece pendiente mientras las acciones confirmadas conservan su estado. Alguien necesita poder ver que el pedido está parcialmente procesado, cuánto tiempo lleva así y qué consecuencia tiene para el siguiente paso. Según la política del negocio, quizá baste con avisar o quizá haya que detener una actividad posterior.
Esa vista del pedido completo no surge automáticamente por conectar consumidores. Hay que decidir qué sistema la presenta y quién se hace cargo cuando una etapa supera el plazo. De lo contrario, todos pueden tener una pieza técnicamente correcta y el cliente seguir sin saber qué ocurre.
El papel de una comprobación periódica
Las notificaciones pueden perderse por errores de configuración, periodos de indisponibilidad o contratos de entrega insuficientes. Un proceso programado de reconciliación puede comparar registros y localizar diferencias. Esto no significa ejecutar dos veces el mismo trabajo sin control. Ambos caminos deben utilizar los mismos identificadores y reglas de deduplicación. La reconciliación comprueba lo ocurrido y recupera faltantes de forma deliberada.
La combinación de eventos y comprobaciones periódicas suele ser una alternativa razonable cuando se necesita respuesta rápida y también evidencia de completitud. Diseña desde el principio cómo distinguir retrasos normales de ausencias reales.
Un contrato que los consumidores puedan entender
Un evento necesita significado estable. Documenta qué representa, qué identificador utiliza, cuándo se produce y qué campos son obligatorios. Evita que los consumidores dependan de detalles internos que el productor cambiará sin aviso.
Decide si el mensaje contiene datos suficientes o referencias para consultar el origen. Incluir datos reduce consultas, pero aumenta duplicación e información transportada. Incluir solo referencias introduce dependencia de disponibilidad y puede recuperar un estado posterior. No hay una respuesta universal. Elige según sensibilidad, tamaño, necesidad de reconstrucción histórica y consistencia requerida. Prueba la compatibilidad antes de cambiar el esquema.
Qué mirar cuando algo se retrasa
Monitoriza retraso desde el origen, antigüedad de pendientes, errores, repeticiones y casos enviados a revisión. La salud del intermediario no demuestra que los consumidores estén cumpliendo el resultado de negocio. Define límites de reintento y un destino para mensajes que no pueden procesarse. Conserva contexto suficiente para corregirlos y reproducirlos sin duplicar acciones. La recuperación debe ser una operación controlada, no un botón utilizado a ciegas.
Prueba interrupciones, duplicados, entradas desordenadas y picos de carga. Incluye también qué ocurre cuando un consumidor vuelve después de estar detenido y necesita ponerse al día.
Vuelve ahora a la petición de «tiempo real». Si el resultado puede esperar hasta el siguiente lote y el volumen lo permite, una ejecución programada puede ser suficiente. Si unos minutos cambian el valor de la respuesta, o varios consumidores necesitan reaccionar por separado, los eventos merecen la complejidad adicional. En cualquiera de los dos casos seguirás necesitando permisos, estado visible y una recuperación comprobada.
Para revisar una integración con DigitalCube, lleva el plazo que necesita el negocio y un ejemplo de lo que ocurre cuando se incumple. Es más fácil discutir una venta que no llegó a facturación que una aspiración abstracta de inmediatez. La arquitectura debe permitir explicar dónde está ese pedido, incluso el día en que una de las piezas deje de responder.