Un recorrido, clonado por hotel, no un recorrido con un if/else

Si preguntas a la mayoría de constructores de flujos de trabajo cómo ejecutar el mismo recorrido del huésped en una docena de establecimientos, la respuesta suele ser un único recorrido con un selector de establecimiento añadido al disparador, una rama if/else enterrada tres nodos más abajo que dice "si hotel_id es igual a X, haz esto; si no, haz aquello". En el lienzo parece eficiente: un recorrido, un único lugar que editar, una sola fuente de verdad. También es lo primero que se rompe en cuanto dos establecimientos necesitan de verdad tiempos distintos, textos distintos o un servicio que solo ofrece uno de ellos.

Un constructor de recorridos multiestablecimiento real para un grupo hotelero no mete todo en un monstruo lleno de ramas. Clona. El mismo recorrido lógico existe una vez por establecimiento, cada uno conectado a su propio disparador, cada uno editable por separado sin tocar los otros once.

Los mismos tres pasos, creados una vez por hotel

Tomemos una secuencia sencilla posterior a la llegada: enviar información general después del check-in, continuar con los servicios disponibles y comprobar más tarde el nivel de satisfacción. Tres pasos, una estructura evidente. Un grupo que gestiona una docena de establecimientos no lo crea como un único recorrido con un conmutador de establecimiento oculto dentro del primer nodo. Crea la misma estructura de tres pasos una docena de veces, una por hotel, cada una con su propio disparador de huésped con check-in realizado.

Eso suena a más mantenimiento hasta que lo pones en marcha. Un establecimiento que añade un spa quiere que el paso de "servicios disponibles" lo mencione. Un establecimiento que cierra por una reforma en temporada media quiere pausar toda la secuencia. Ninguno de esos cambios debería arriesgarse a tocar el flujo de un establecimiento hermano y, en el modelo clonado, no lo hace, porque no hay ningún nodo compartido en el que puedan chocar. La versión con if/else no puede garantizarlo: un error en la rama compartida es un error en el flujo de todos los establecimientos a la vez.

La misma decisión estructural aparece también en recorridos mucho más simples. Un flujo de confirmación de reserva, apenas un disparador de reserva creada filtrado hasta quedarse con las reservas confirmadas, sigue el mismo patrón de un recorrido por establecimiento en lugar de un único recorrido que filtre tanto por "confirmada" como por "qué hotel". Los recorridos simples y los complejos reciben el mismo tratamiento, porque la razón para clonar no es la complejidad. Es el aislamiento.

Prevención de inscripciones duplicadas en el constructor de recorridos: modo ventana frente a modo por entidad

Clonar por establecimiento resuelve el problema de enviar el texto equivocado al hotel equivocado. No resuelve otro más sutil: qué cuenta como el mismo disparador ejecutándose dos veces. Un huésped hace check-in y, una hora después, algo aguas arriba reenvía el mismo evento: un webhook reintentado, una resincronización nocturna que se solapa con una actualización en vivo. ¿Recibe ese huésped dos veces la secuencia de bienvenida?

Cada disparador capaz de trabajar con entidades, reserva o huésped, lleva su propia configuración de deduplicación para responder a eso: una ventana de deduplicación medida en horas, un modo de deduplicación y una clave de entidad para deduplicar. Existen dos modos, y significan cosas realmente distintas. El modo ventana trata cualquier disparador duplicado dentro de la ventana como un único evento, sin más, con independencia de qué reserva o huésped concreto lo haya provocado. El modo por entidad es más preciso: permite una inscripción por cada id de reserva o huésped distinto dentro de esa misma ventana, de modo que dos reservas diferentes del mismo huésped pueden generar inscripciones separadas.

Esa distinción importa porque los dos modos de fallo apuntan en direcciones opuestas. El modo ventana aplicado a un disparador que debería haber sido por entidad descarta silenciosamente la segunda inscripción legítima de un huésped. El modo por entidad aplicado a un disparador que debería haberse deduplicado por ventana permite que un evento verdaderamente duplicado envíe dos veces un mensaje de bienvenida. El ajuste no es decorativo. Decide si un huésped con dos estancias solapadas recibe dos flujos de confirmación o uno, y si una integración de sincronización ruidosa satura a un huésped o queda absorbida sin hacer ruido.

Dos hoteles, dos respuestas distintas a la misma pregunta

Como el ajuste vive en el disparador, no en la plantilla del recorrido, dos establecimientos que ejecutan un recorrido visualmente idéntico pueden configurarlo de formas completamente distintas. Una secuencia de bienvenida disparada por el check-in es el tipo de recorrido que la mayoría de establecimientos quiere deduplicar por ventana: un evento de check-in, por muchas veces que una integración vuelva a dispararlo, debería producir exactamente un flujo de bienvenida para esa estancia. Un recorrido que reacciona a reservas, donde el mismo huésped puede reservar legítimamente dos estancias separadas dentro de la ventana de deduplicación, pide un enfoque por entidad: cada reserva es su propio evento y merece su propia inscripción, sin colapsar en un "este huésped ya ha activado algo hace poco".

Esta es la parte que un recorrido compartido con if/else no puede expresar en absoluto. Un único recorrido tiene un único disparador, y un único disparador tiene una única configuración de deduplicación. Al separarlo en un recorrido por establecimiento, el disparador de cada establecimiento contiene su propia respuesta a qué cuenta aquí como duplicado, y ninguno tiene que ceder para parecerse al otro.

Lo que un flujo de trabajo escalable para una cadena hotelera tiene que resistir de verdad

Nada de esto importa si clonar un recorrido en una docena de establecimientos implica doce veces más carga de ejecución y esa carga no se gestiona. Con la configuración actual de workers, veinte workers ejecutándose por ciclo cron, la plataforma procesa 1,200 ejecuciones de recorridos por hora, lo que equivale a un techo de 28,800 al día. No es una cifra de marketing redondeada al alza. Es el rendimiento real dentro del que debe encajar este patrón.

Dos mecánicas impiden que ese techo se convierta en una carrera cuando la automatización se despliega por varios establecimientos a la vez. Las ejecuciones se reclaman mediante un mecanismo atómico que garantiza que dos workers nunca puedan tomar la misma, así que clonar un recorrido en una docena de establecimientos no supone el riesgo de que dos workers procesen dos veces el mismo paso del mismo huésped. Y las reclamaciones se distribuyen por turnos entre clientes, de modo que un grupo hotelero con un lote de recorridos inusualmente activo no puede dejar bloqueados detrás en la cola los envíos de todos los demás clientes. Un constructor de recorridos para un grupo hotelero solo se mantiene honesto a escala si una semana intensa para un grupo no degrada una semana tranquila para otro, y eso se impone en la cola, no se deja que la carga se equilibre por sí sola.

El modo de fallo que no deja tirado a un huésped

A veces los workers se caen a mitad de ejecución. Eso ocurre en cualquier sistema basado en colas, no es un defecto específico de este. Lo importante es qué pasa después. Una comprobación de salud se ejecuta cada cinco minutos y restablece automáticamente cualquier ejecución que lleve más de 30 minutos en progreso. Sin eso, un worker caído dejaría a un huésped atascado permanentemente a mitad de recorrido, sin que el sistema vuelva a retomarlo. Simplemente se habría detenido.

Es una mecánica pequeña al lado de los modos de deduplicación y los techos de rendimiento, pero es la que convierte el modelo clonado por establecimiento de una idea limpia en algo capaz de sobrevivir a un mal despliegue a las dos de la mañana sin que nadie note que un huésped se ha caído de una secuencia.

Cuando esto deja de ser una decisión de diseño y empieza a ser aritmética

El patrón de un recorrido por establecimiento no es una filosofía sobre el orden. Es lo que resulta de tomarse en serio dos cosas a la vez: que una docena de establecimientos siempre querrá tiempos y contenidos ligeramente distintos, y que duplicado no significa lo mismo para un evento de check-in que para una reserva. Una rama if/else enterrada en un recorrido puede simular lo primero durante un tiempo. No tiene forma de expresar lo segundo, porque en un disparador compartido no hay ningún sitio donde poner dos respuestas distintas a qué cuenta como una inscripción.

Nada de eso sale gratis. Está limitado por un número real de ejecuciones por hora. Un mecanismo de reclamación impide que dos workers procesen nunca la misma ejecución dos veces, y una comprobación de salud rescata lo que se haya quedado atascado cuando un worker se cae a mitad de paso. Un constructor de flujos de trabajo para un grupo hotelero tiene que sostener las tres cosas a la vez, no solo la parte que queda bien en una demo con un único establecimiento abierto.