Saltar a contenido

Detour

1. Nombre del Patrón

  • Nombre oficial: Detour
  • Categoría: System Management (Gestión del Sistema de Mensajería)
  • Traducción contextual: Desvío

2. Resumen Ejecutivo

Detour es el patrón que permite desviar temporalmente el flujo de mensajes a través de una ruta alternativa — típicamente un paso adicional de validación, inspección o transformación — sin modificar la ruta principal de forma permanente. Es un mecanismo de "bypass controlado" que se activa y desactiva dinámicamente según las necesidades operacionales.

El problema que resuelve es diagnóstico y de compliance: ¿cómo se inserta temporalmente un paso adicional de procesamiento en un flujo de mensajes en producción sin modificar el código, sin redesplegar y sin afectar permanentemente la arquitectura? Detour responde proporcionando un punto de decisión configurable (Context-Based Router controlado por un switch) que puede redirigir mensajes a una ruta alternativa cuando se activa, y volver a la ruta directa cuando se desactiva.

La vigencia del patrón es media pero significativa en contextos específicos. Los feature flags modernos implementan Detour a nivel de lógica de aplicación. Los canary deployments y traffic shifting en service meshes son formas de Detour a nivel de infraestructura. Las políticas de auditoría temporal (enviar transacciones por un paso extra de validación durante un período de inspección regulatoria) son la manifestación más directa del patrón.

3. Definición Detallada

Propósito

Detour proporciona un mecanismo para insertar condicionalmente pasos adicionales de procesamiento en un flujo de mensajes, controlado por un switch externo (típicamente administrado vía Control Bus). Su propósito es permitir que la ruta que sigue un mensaje sea configurable en tiempo de ejecución, habilitando escenarios como validación temporal, auditoría por demanda, debugging en producción y routing condicional para testing.

Lógica Arquitectónica

Un flujo de mensajes en producción tiene una ruta definida: entrada → procesamiento → salida. Hay escenarios donde se necesita insertar un paso intermedio temporalmente:

  • Durante una auditoría regulatoria, todas las transacciones deben pasar por un paso de validación adicional que normalmente no existe.
  • Durante la migración a un nuevo sistema, los mensajes deben pasar por un paso de comparación que verifica que el nuevo sistema produce los mismos resultados que el antiguo.
  • Durante la investigación de un bug, los mensajes deben pasar por un paso de logging detallado que capture información extra.

Sin Detour, estas necesidades requieren modificar el flujo (añadir el paso), redesplegar, y luego volver a modificar y redesplegar para quitar el paso cuando ya no se necesita. Detour elimina este ciclo introduciendo un punto de decisión permanente que, cuando está desactivado, deja pasar los mensajes directamente, y cuando se activa, los desvía por la ruta alternativa.

La activación y desactivación del Detour se controla externamente — idealmente a través de un Control Bus — lo que permite al operador o a un sistema automatizado activar el desvío en segundos y desactivarlo igual de rápido.

Principio de Diseño Subyacente

El principio es routing condicional controlado externamente. A diferencia de un Content-Based Router (que decide la ruta basándose en el contenido del mensaje), el Detour decide la ruta basándose en una condición externa (un flag, una configuración, un comando del Control Bus). El mensaje no determina si toma el desvío; el operador o el sistema lo determina.

Problema Estructural que Resuelve

En un sistema de integración rígido, la ruta de un mensaje está hardcodeada. Cualquier cambio en la ruta requiere un cambio de código y un redespliegue. Detour introduce flexibilidad en la ruta sin sacrificar la definición clara del flujo normal: la ruta principal está definida, la ruta de desvío está definida, y un switch controla cuál se usa.

Contexto en el que Emerge

Detour emerge cuando hay necesidad recurrente de insertar pasos temporales en flujos de producción. Si la necesidad es una sola vez, un redespliegue puede ser aceptable. Si la necesidad es recurrente (auditorías periódicas, períodos de migración, investigaciones frecuentes), Detour justifica su overhead permanente (el punto de decisión está siempre presente, aunque normalmente inactivo).

Relación con Sistemas Distribuidos

Detour es una forma de traffic management controlada externamente. En el contexto de service meshes, corresponde a las funcionalidades de traffic shifting y traffic mirroring de Istio o Linkerd, donde un operador puede redirigir un porcentaje del tráfico a una ruta alternativa sin cambiar la aplicación.

4. Problema que Resuelve

El Problema Antes del Patrón

Sin Detour, cuando se necesita insertar un paso temporal en un flujo de producción:

  • Modificación de código: se modifica el flujo para añadir el paso adicional. Esto requiere desarrollo, testing y un ciclo de deploy.
  • Riesgo de regresión: el cambio puede introducir errores en el flujo principal.
  • Latencia operacional: desde que se identifica la necesidad (por ejemplo, el regulador solicita validación adicional) hasta que el paso está activo pueden pasar horas o días.
  • Olvido de remoción: después de que la necesidad temporal desaparece, el paso adicional puede quedar en el flujo indefinidamente ("temporalmente permanente").
  • Doble deploy: se necesitan dos despliegues — uno para añadir el paso y otro para quitarlo — cada uno con su riesgo.

Síntomas del Problema

  • Flujos de producción que acumulan pasos "temporales" que nadie se atreve a quitar.
  • Incapacidad de responder rápidamente a solicitudes de auditoría o compliance.
  • Pasos de debugging que se dejan en producción y afectan la latencia.
  • Ciclos de deploy asociados a necesidades operacionales que deberían ser configuración, no código.

Impacto Operativo y Arquitectónico

  • MTTR alto para diagnósticos que requieren pasos intermedios.
  • Riesgo acumulado por código temporal que se vuelve permanente.
  • Incapacidad de cumplir con requisitos regulatorios de validación adicional dentro del plazo exigido.

Riesgos Si No Se Implementa Correctamente

  • Detour que nunca se desactiva: el switch queda activado permanentemente, añadiendo latencia innecesaria al flujo principal.
  • Ruta de desvío no probada: la ruta alternativa no se prueba regularmente y falla cuando se activa en un momento crítico.
  • Impacto en rendimiento: el paso adicional del desvío puede ser costoso (validación compleja, llamada a servicio externo) y afectar la latencia del flujo principal.

Ejemplos Reales

  • Banca: durante un período de auditoría trimestral, el regulador exige que todas las transacciones internacionales pasen por un paso adicional de verificación anti-lavado. El paso se activa al inicio del período y se desactiva al final.
  • Seguros: durante la migración de un motor de cálculo de primas, todas las solicitudes de cotización pasan por ambos motores (antiguo y nuevo) para comparar resultados. El desvío se desactiva cuando se confirma la paridad.
  • E-commerce: durante una investigación de fraude, los pedidos de cierta región se desvían por un paso adicional de scoring de riesgo.

5. Contexto de Aplicación

Cuándo Usarlo

  • Cuando se necesitan pasos temporales de validación, auditoría o debugging que se activan y desactivan periódicamente.
  • Cuando el tiempo de respuesta para activar el paso adicional debe ser inmediato (no puede esperar un ciclo de deploy).
  • Cuando la ruta alternativa está bien definida de antemano (no es improvisación, sino una ruta planificada que se activa bajo demanda).
  • Cuando se necesita comparación entre flujos (antiguo vs. nuevo) durante migraciones.

Cuándo No Usarlo

  • Cuando el paso adicional es permanente — en ese caso, simplemente inclúyalo en el flujo principal.
  • Cuando la lógica de routing depende del contenido del mensaje — use Content-Based Router.
  • Cuando la necesidad es única e irrepetible — un redespliegue puede ser más simple que implementar Detour.

Precondiciones

  • La ruta de desvío debe estar implementada y desplegada, lista para activarse.
  • Debe existir un mecanismo de switch externo (Control Bus, feature flag, configuración dinámica).
  • El punto de decisión del Detour debe estar insertado en el flujo principal.

Restricciones

  • El Detour añade un punto de decisión en el flujo principal, lo que introduce una pequeña latencia incluso cuando el desvío está desactivado (la evaluación del switch).
  • La ruta de desvío debe ser compatible con los mensajes del flujo principal (mismos formatos, mismos protocolos).
  • La activación/desactivación debe ser atómica: no debe haber ventana donde algunos mensajes tomen el desvío y otros no de forma inconsistente (salvo que sea intencional, como en canary deployments).

6. Fuerzas Arquitectónicas

Flexibilidad Operacional vs. Complejidad del Flujo

Detour añade flexibilidad operacional (activar/desactivar pasos dinámicamente) pero complejiza el flujo de mensajes: la ruta del mensaje ya no es lineal y determinista, sino condicional. Esto puede dificultar la comprensión del flujo y el debugging.

Latencia del Flujo Normal vs. Capacidad de Diagnóstico

Incluso cuando el Detour está desactivado, el punto de decisión existe en el flujo y consume un tiempo mínimo de evaluación. La tensión está entre la preparación para diagnóstico y el overhead en operación normal.

Preparación vs. Costo de Mantenimiento

La ruta de desvío debe mantenerse funcional y probada aunque se use infrecuentemente. Esto tiene un costo de mantenimiento (testing, compatibilidad con cambios en el flujo principal) que debe justificarse con la frecuencia de uso esperada.

Consistencia del Flujo vs. Temporalidad del Cambio

Cuando el Detour se activa, hay un período transitorio donde algunos mensajes ya en tránsito no pasan por el desvío y otros sí. Esta inconsistencia temporal puede ser problemática para flujos que requieren procesamiento uniforme.

Control Centralizado vs. Autonomía Local

El switch del Detour es típicamente centralizado (Control Bus, feature flag). Esto centraliza la decisión pero puede crear latencia si el componente local debe consultar un servicio remoto para evaluar el switch.

7. Estructura Conceptual del Patrón

Actores o Componentes Involucrados

  1. Switch (Interruptor de Control): mecanismo externo que determina si el Detour está activo o inactivo.
  2. Detour Router (Punto de Decisión): componente en el flujo que evalúa el switch y decide si enviar el mensaje por la ruta directa o por el desvío.
  3. Ruta Directa: el camino normal del mensaje cuando el desvío está desactivado.
  4. Ruta de Desvío: el camino alternativo que incluye pasos adicionales (validación, logging, comparación).
  5. Punto de Reincorporación: el punto donde la ruta de desvío se reconecta con el flujo principal.
  6. Control Bus: mecanismo para activar/desactivar el switch.

Flujo Lógico

flowchart TD
    A([Mensaje llega]) --> B[Detour Router]
    B --> C{Evalúa switch}
    C -->|INACTIVO: operación normal| D([Ruta directa al Destino])
    C -->|ACTIVO: período de auditoría| E[Ruta Alternativa]
    E -->|Validación, logging, etc.| F[Reincorporación al flujo principal]
    F --> D

    subgraph Activación
        G([Operador / Automatización]) -->|Comando de activación| H[Control Bus]
        H -->|Propaga comando| I[Detour Router cambia switch a ACTIVO]
    end

Responsabilidades

Componente Responsabilidad
Switch Almacenar el estado (activo/inactivo) del desvío
Detour Router Evaluar el switch y dirigir mensajes a la ruta correcta
Ruta de Desvío Ejecutar los pasos adicionales sin alterar el mensaje (o alterándolo de forma controlada)
Punto de Reincorporación Garantizar que el mensaje continúa el flujo normal después del desvío
Control Bus Transmitir comandos de activación/desactivación

Decisiones de Diseño Clave

  1. Evaluación del switch: ¿local (variable en memoria actualizada por evento) o remota (consulta a servicio externo en cada mensaje)?
  2. Granularidad: ¿todo el tráfico se desvía, o solo un porcentaje (canary)?
  3. Transparencia: ¿el mensaje sabe que fue desviado? ¿Se marca con un header?
  4. Timeout de activación: ¿el Detour se desactiva automáticamente después de un período o requiere desactivación explícita?
  5. Impacto en el mensaje: ¿la ruta de desvío modifica el mensaje o solo lo inspecciona?

8. Ejemplo Arquitectónico Detallado

Dominio: Banca — Validación Adicional de Transacciones durante Auditoría

Contexto del Negocio

Un banco internacional procesa 2 millones de transacciones internacionales diarias. El regulador bancario realiza auditorías trimestrales donde exige que, durante un período de 2 semanas, todas las transacciones internacionales superiores a 10,000 EUR pasen por un paso adicional de verificación anti-lavado de dinero (AML) con un motor de reglas externo contratado específicamente para la auditoría.

Este paso adicional no es necesario fuera del período de auditoría (el banco tiene su propio motor AML en el flujo permanente), pero el regulador exige la verificación independiente durante la inspección.

Necesidad de Integración

El banco necesita:

  1. Activar el paso de verificación AML externo al inicio del período de auditoría.
  2. Que todas las transacciones > 10,000 EUR pasen por el verificador externo sin interrumpir el flujo normal.
  3. Registrar los resultados de la verificación externa para el informe de auditoría.
  4. Desactivar el paso al final del período de auditoría.
  5. Todo esto sin modificar código ni redesplegar.

Sistemas Involucrados

  1. Transaction Router: router que dirige transacciones al procesador correspondiente.
  2. Internal AML Engine: motor AML propio del banco (siempre activo).
  3. External AML Verifier: servicio del auditor externo (solo activo durante auditorías).
  4. Detour Router: punto de decisión que evalúa si activar el desvío.
  5. Control Bus: canal para activar/desactivar el desvío.
  6. Audit Logger: servicio que registra los resultados de la verificación externa.
  7. Transaction Processor: destino final que ejecuta la transacción.

Diseño del Detour

Flujo normal (Detour DESACTIVADO):
Transaction → Internal AML → Transaction Processor

Flujo con Detour (ACTIVADO):
Transaction → Internal AML → [Detour Router] → External AML Verifier 
                                                      ↓
                                               Audit Logger
                                                      ↓
                                            Transaction Processor

Decisiones Arquitectónicas

  1. Detour después del AML interno: el desvío se inserta después del motor AML propio del banco, no antes. Así, las transacciones ya filtradas por el motor interno también pasan por el externo durante la auditoría.

  2. Switch basado en feature flag: el estado del Detour se almacena en un sistema de feature flags (Unleash) que el Detour Router consulta localmente (SDK con cache, no llamada remota en cada transacción).

  3. Filtro de monto: aunque el Detour Router evalúa el switch, también aplica el filtro de monto (> 10,000 EUR). Las transacciones menores siguen la ruta directa incluso con el Detour activado.

  4. No-blocking: si el External AML Verifier no responde en 5 segundos, la transacción continúa (el desvío no debe bloquear el flujo principal). El timeout se registra en el Audit Logger.

9. Desarrollo Paso a Paso del Ejemplo

Paso 1: Preparación (antes del período de auditoría)

El equipo de operaciones configura el Detour:

  1. Despliega el conector con el External AML Verifier (la integración con el servicio del auditor ya está implementada y probada, pero desactivada).
  2. Configura el feature flag audit.external-aml.enabled en Unleash con estado disabled.
  3. Configura las condiciones del flag: solo aplica a transacciones con amount > 10000 y currency = EUR y type = international.
  4. Verifica la ruta de desvío en el entorno de staging con transacciones de prueba.

Paso 2: Activación del Detour

El primer día del período de auditoría, el responsable de compliance activa el flag:

{
  "feature": "audit.external-aml.enabled",
  "environment": "production",
  "state": "enabled",
  "activated_by": "compliance-officer-mlopez",
  "reason": "Inicio auditoría trimestral Q1-2026",
  "scheduled_deactivation": "2026-04-21T23:59:59Z"
}

El cambio se propaga a todos los Detour Routers en menos de 10 segundos (vía SDK streaming de Unleash).

Paso 3: Procesamiento con Detour Activo

Una transacción de 25,000 EUR de Madrid a Frankfurt llega al flujo:

  1. Internal AML Engine: evalúa la transacción con sus reglas internas → resultado: PASS.
  2. Detour Router: evalúa el flag audit.external-aml.enabled → ACTIVO. Verifica monto > 10,000 EUR → cumple. Desvía al External AML Verifier.
  3. External AML Verifier: recibe la transacción, aplica sus propias reglas → resultado: PASS, risk_score: 0.12.
  4. Audit Logger: registra el resultado de la verificación externa: transaction_id, internal_result, external_result, risk_score, timestamp.
  5. Transaction Processor: la transacción continúa su procesamiento normal.

Paso 4: Manejo de Transacciones Bajo el Umbral

Una transacción de 500 EUR del mismo período:

  1. Internal AML Engine: evalúa → PASS.
  2. Detour Router: evalúa el flag → ACTIVO, pero el monto (500 EUR) no supera el umbral (10,000 EUR). La transacción sigue por la ruta directa sin desvío.

Paso 5: Desactivación del Detour

Al finalizar el período de auditoría, el scheduler desactiva automáticamente el flag según la fecha programada. Alternativamente, el compliance officer desactiva manualmente:

{
  "feature": "audit.external-aml.enabled",
  "state": "disabled",
  "deactivated_by": "compliance-officer-mlopez",
  "reason": "Fin auditoría trimestral Q1-2026"
}

Todas las transacciones vuelven a la ruta directa.

Paso 6: Generación de Informe de Auditoría

El Audit Logger contiene todos los registros del período de auditoría. Se genera un informe con: - Total de transacciones verificadas externamente. - Distribución de resultados (PASS, FLAG, REJECT). - Discrepancias entre motor interno y externo. - Tiempos de respuesta del verificador externo. - Transacciones donde el timeout fue alcanzado.

10. Diagrama Técnico del Patrón

Código Python con diagrams

Diagrama General

Diagrama AWS

Diagrama Azure

Ver / Copiar código de los diagramas 
from diagrams import Diagram, Cluster, Edge
from diagrams.onprem.queue import Kafka
from diagrams.onprem.compute import Server
from diagrams.onprem.database import PostgreSQL
from diagrams.onprem.client import User
from diagrams.programming.flowchart import Decision

with Diagram("Detour - Banking AML Audit", show=False, direction="LR"):

    with Cluster("Transaction Flow"):
        tx_in = Kafka("Transactions\nInbound")
        internal_aml = Server("Internal\nAML Engine")

    with Cluster("Detour Mechanism"):
        detour_router = Server("Detour\nRouter")
        flag_store = Server("Feature Flag\n(Unleash)")

    with Cluster("Detour Route (Active During Audit)"):
        external_aml = Server("External AML\nVerifier")
        audit_logger = Server("Audit\nLogger")
        audit_db = PostgreSQL("Audit\nRecords")

    with Cluster("Normal Continuation"):
        tx_processor = Server("Transaction\nProcessor")

    with Cluster("Control Plane"):
        compliance = User("Compliance\nOfficer")
        scheduler = Server("Scheduler\n(Auto-Deactivate)")

    # Normal flow
    tx_in >> internal_aml >> detour_router

    # Detour check
    flag_store >> Edge(style="dotted", label="flag state") >> detour_router

    # Detour route (when active)
    detour_router >> Edge(label="detour ON\n>10K EUR") >> external_aml
    external_aml >> audit_logger >> audit_db
    audit_logger >> tx_processor

    # Direct route (when inactive)
    detour_router >> Edge(label="detour OFF\nor <10K") >> tx_processor

    # Control
    compliance >> flag_store
    scheduler >> flag_store

from diagrams import Diagram, Cluster, Edge
from diagrams.onprem.client import User
from diagrams.aws.compute import Lambda
from diagrams.aws.database import Dynamodb
from diagrams.aws.integration import SQS, Eventbridge, StepFunctions
from diagrams.aws.management import SystemsManager


with Diagram("Detour - Banking AML Audit (AWS)", show=False, direction="LR"):

    with Cluster("Transaction Flow"):
        tx_in = SQS("Transactions\nInbound")
        internal_aml = Lambda("Internal\nAML Engine")

    with Cluster("Detour Mechanism"):
        detour_router = StepFunctions("Detour\nStep Function")
        flag_store = SystemsManager("AppConfig\nFeature Flag")

    with Cluster("Detour Route (Active During Audit)"):
        external_aml = Lambda("External AML\nVerifier")
        audit_logger = Lambda("Audit\nLogger")
        audit_db = Dynamodb("Audit\nRecords")

    with Cluster("Normal Continuation"):
        tx_processor = Lambda("Transaction\nProcessor")

    with Cluster("Control Plane"):
        compliance = User("Compliance\nOfficer")
        scheduler = Eventbridge("EventBridge\nScheduler\n(Auto-Deactivate)")

    # Normal flow
    tx_in >> internal_aml >> detour_router

    # Detour check
    flag_store >> Edge(style="dotted", label="flag state") >> detour_router

    # Detour route (when active)
    detour_router >> Edge(label="detour ON\n>10K EUR") >> external_aml
    external_aml >> audit_logger >> audit_db
    audit_logger >> tx_processor

    # Direct route (when inactive)
    detour_router >> Edge(label="detour OFF\nor <10K") >> tx_processor

    # Control
    compliance >> flag_store
    scheduler >> flag_store

from diagrams import Diagram, Cluster, Edge
from diagrams.onprem.client import User
from diagrams.azure.compute import FunctionApps, ContainerApps
from diagrams.azure.database import CosmosDb
from diagrams.azure.integration import ServiceBus, APIManagement
from diagrams.azure.general import Helpsupport

with Diagram("Detour - Banking AML Audit (Azure)", show=False, direction="LR"):

    with Cluster("Transaction Flow"):
        tx_in = ServiceBus("Transactions\nInbound Topic")
        internal_aml = FunctionApps("Internal\nAML Engine")

    with Cluster("Detour Mechanism"):
        apim = APIManagement("API Management\n(Detour Policy)")
        app_config = Helpsupport("Azure App\nConfiguration\n(Feature Flag)")

    with Cluster("Detour Route (Active During Audit)"):
        external_aml = ContainerApps("External AML\nVerifier")
        audit_logger = FunctionApps("Audit\nLogger Function")
        audit_db = CosmosDb("Audit\nRecords")

    with Cluster("Normal Continuation"):
        tx_processor = FunctionApps("Transaction\nProcessor")

    with Cluster("Control Plane"):
        compliance = User("Compliance\nOfficer")
        scheduler = FunctionApps("Timer Function\n(Auto-Deactivate)")

    # Normal flow
    tx_in >> internal_aml >> apim

    # Detour check
    app_config >> Edge(style="dotted", label="feature flag") >> apim

    # Detour route (when active)
    apim >> Edge(label="detour ON\n>10K EUR") >> external_aml
    external_aml >> audit_logger >> audit_db
    audit_logger >> tx_processor

    # Direct route (when inactive)
    apim >> Edge(label="detour OFF\nor <10K") >> tx_processor

    # Control
    compliance >> app_config
    scheduler >> app_config

Explicación del Diagrama

El diagrama muestra el mecanismo de Detour para la auditoría AML bancaria:

  1. Las transacciones llegan y pasan por el Internal AML Engine (siempre activo).
  2. El Detour Router consulta el Feature Flag para determinar si el desvío está activo.
  3. Si el desvío está activo y la transacción supera 10,000 EUR, se dirige al External AML Verifier.
  4. Los resultados se registran en el Audit Logger y se almacenan para el informe de auditoría.
  5. Si el desvío está inactivo (o el monto es menor), la transacción va directamente al Transaction Processor.
  6. El Compliance Officer y el Scheduler controlan la activación/desactivación del flag.

Correspondencia Patrón ↔ Diagrama

Concepto del Patrón Componente del Diagrama
Switch Feature Flag (Unleash)
Detour Router Detour Router
Ruta Directa Detour Router → Transaction Processor
Ruta de Desvío Detour Router → External AML → Audit Logger → Transaction Processor
Control Bus Compliance Officer / Scheduler → Feature Flag

11. Beneficios

Impacto Técnico

  • Cero redespliegues para cambios temporales: la activación y desactivación del desvío no requiere cambios de código ni ciclos de deploy.
  • Latencia mínima cuando está desactivado: la evaluación del switch (consulta local al SDK del feature flag) tiene latencia de microsegundos.
  • Ruta de desvío pre-probada: como la ruta alternativa está implementada y desplegada permanentemente, puede probarse en staging antes de activarse en producción.
  • Activación/desactivación instantánea: el cambio de estado del flag se propaga en segundos.

Impacto Organizacional

  • Autonomía de compliance: el equipo de compliance puede activar el paso de auditoría sin depender del equipo de desarrollo.
  • Reducción de presión operacional: no hay necesidad de programar ventanas de despliegue ni coordinación entre equipos para activar un paso temporal.
  • Documentación implícita: el feature flag y sus condiciones documentan qué paso se activa, bajo qué condiciones y por qué.

Impacto Operacional

  • Respuesta rápida a regulación: ante solicitudes urgentes del regulador, el paso adicional se activa en minutos, no en días.
  • Rollback instantáneo: si la ruta de desvío causa problemas (latencia, errores), se desactiva inmediatamente con un cambio de flag.
  • Auditoría completa: el sistema registra cuándo se activó el desvío, quién lo activó, cuántas transacciones se desviaron y los resultados.

12. Desventajas y Riesgos

Complejidad Añadida

  • Punto de decisión permanente: el Detour Router existe en el flujo permanentemente, añadiendo un componente más que mantener y monitorear.
  • Ruta dormida: la ruta de desvío debe mantenerse funcional aunque no se use durante meses. Las dependencias (External AML Verifier) pueden cambiar, y la ruta puede romperse silenciosamente.
  • Testing dual: se deben probar tanto la ruta directa como la ruta de desvío, y las transiciones entre ambas.

Riesgos de Mal Uso

  • Desvío permanente disfrazado: usar Detour para un paso que debería ser permanente, evitando la decisión de incluirlo formalmente en el flujo.
  • Acumulación de desvíos: múltiples Detours encadenados que convierten un flujo simple en un laberinto de rutas condicionales.
  • Desvío sin monitoring: activar un desvío y no monitorear su impacto en latencia y error rate del flujo principal.

Sobreingeniería

  • Detour para un solo uso: si la necesidad de desvío es una sola vez en la vida del sistema, implementar el mecanismo completo es overhead innecesario.
  • Granularidad excesiva: crear un Detour para cada posible variación del flujo en lugar de para las variaciones operacionalmente significativas.

Anti-Patterns Relacionados

  • Spaghetti Detours: múltiples Detours anidados o encadenados que hacen imposible entender qué ruta toma un mensaje.
  • Zombie Detour: un desvío que fue activado "temporalmente" hace meses y nadie se atreve a desactivar porque no se sabe si todavía es necesario.

13. Relación con Otros Patrones

Patrones Complementarios

  • Control Bus (este capítulo): el mecanismo natural para activar/desactivar el Detour.
  • Wire Tap (este capítulo): un Detour puede desviar mensajes a un Wire Tap para inspección temporal.
  • Message History (este capítulo): el mensaje desviado debe registrar en su historia que pasó por la ruta de desvío.
  • Content-Based Router (Capítulo 5): el Detour Router es un router cuya condición es externa (el switch), no el contenido del mensaje.

Patrones que Suelen Aparecer Juntos

  • Detour + Wire Tap: desviar mensajes a un tap de diagnóstico temporal.
  • Detour + Control Bus: gestionar la activación/desactivación del desvío.
  • Detour + Message History: registrar que el mensaje tomó la ruta de desvío.
  • Detour + Test Message: inyectar mensajes de prueba para verificar que la ruta de desvío funciona antes de activarla con tráfico real.

Diferencias con Patrones Similares

  • vs. Content-Based Router: el CBR decide la ruta basándose en el contenido del mensaje; el Detour decide basándose en una condición externa (switch).
  • vs. Wire Tap: el Wire Tap copia mensajes a un canal secundario sin alterar la ruta; el Detour redirige mensajes a una ruta alternativa que incluye pasos adicionales.
  • vs. Recipient List: la Recipient List envía copias a múltiples destinos; el Detour envía el original a una u otra ruta.

Encaje en un Flujo Mayor de Integración

Detour se inserta en un flujo existente como un punto de decisión controlable. No cambia la semántica del flujo — el mensaje llega al mismo destino final por ambas rutas — pero puede añadir efectos secundarios (logging, validación) en la ruta de desvío.

14. Relevancia Actual del Patrón

Evaluación: Relevancia Media

Argumentación

Detour como patrón explícito de integración tiene relevancia media, pero sus manifestaciones modernas son ubicuas:

  • Feature Flags: LaunchDarkly, Unleash, Flagsmith implementan Detour a nivel de lógica de aplicación. La decisión de ejecutar o no un bloque de código basándose en un flag externo es la esencia del Detour.
  • Canary Deployments: enviar un porcentaje del tráfico a la nueva versión de un servicio es un Detour parcial controlado externamente (por Istio VirtualService, Flagger, o Argo Rollouts).
  • Traffic Shifting (Service Mesh): las políticas de traffic shifting de Istio/Linkerd permiten redirigir tráfico entre versiones de un servicio — el equivalente moderno del Detour.
  • Dark Launching: desplegar funcionalidad nueva pero oculta, activándola solo para ciertos usuarios o condiciones, es un Detour a nivel de producto.

La razón de la evaluación "media" es que el patrón no se implementa frecuentemente como un componente de infraestructura de messaging dedicado, sino que se implementa a nivel de aplicación (feature flags) o de infraestructura (service mesh). El concepto es altamente vigente; la implementación como componente de messaging dedicado es menos común.

Cómo Se Implementa Hoy

Tecnología Implementación de Detour Nivel
LaunchDarkly/Unleash Feature flags con condiciones Aplicación
Istio VirtualService Traffic routing con weights Infraestructura
Argo Rollouts Canary con análisis automatizado Despliegue
Apache Camel Choice + Control Bus Integración
Spring Integration Router + Feature Flag Integración
AWS AppConfig Feature flags con deployment strategy Aplicación

15. Implementación en Arquitecturas Modernas

Feature Flags con Unleash

// Detour Router implementado como feature flag check
if (unleash.isEnabled("audit.external-aml", 
    UnleashContext.builder()
        .addProperty("amount", transaction.getAmount().toString())
        .addProperty("currency", transaction.getCurrency())
        .build())) {
    // Detour route: verificación AML externa
    ExternalAmlResult result = externalAmlService.verify(transaction);
    auditLogger.log(transaction, result);
}
// Flujo normal continúa independientemente
transactionProcessor.process(transaction);

Istio Traffic Shifting

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: transaction-processor
spec:
  hosts:
  - transaction-processor
  http:
  - match:
    - headers:
        x-audit-period:
          exact: "active"
    route:
    - destination:
        host: transaction-processor-with-external-aml
        port:
          number: 8080
  - route:
    - destination:
        host: transaction-processor
        port:
          number: 8080

Apache Camel Detour

from("kafka:transactions.inbound")
    .process(internalAmlEngine)
    .choice()
        .when(simple("${bean:detourSwitch.isActive('external-aml')}"))
            .to("direct:external-aml-detour")
        .end()
    .to("kafka:transactions.processed");

from("direct:external-aml-detour")
    .to("http:external-aml-verifier/verify")
    .to("direct:audit-logger");

Spring Cloud Gateway con Feature Flag

spring:
  cloud:
    gateway:
      routes:
      - id: detour-aml
        uri: http://external-aml-verifier
        predicates:
        - FeatureFlag=audit.external-aml.enabled
        - Amount=gt,10000

16. Consideraciones de Gobierno y Operación

Observabilidad

  • Métricas del Detour: porcentaje de mensajes desviados, latencia adicional de la ruta de desvío, error rate de la ruta de desvío.
  • Dashboard de estado: visualización clara de qué Detours están activos, desde cuándo, activados por quién.
  • Alertas: Detour activo más de N días sin desactivación programada, error rate de la ruta de desvío > umbral, latencia de la ruta de desvío > SLA.

Monitoreo de Ruta Dormida

  • La ruta de desvío debe verificarse periódicamente (health checks, mensajes de prueba) incluso cuando está desactivada.
  • Las dependencias de la ruta de desvío (servicios externos, credenciales) deben monitorearse.

Lifecycle Management

  • Cada Detour debe tener un owner, una justificación, una fecha de revisión y una fecha de expiración.
  • Un proceso periódico debe revisar los Detours activos y validar que siguen siendo necesarios.
  • Los Detours sin actividad reciente deben evaluarse para eliminación.

Seguridad

  • La activación/desactivación de Detours debe requerir permisos específicos (no cualquier operador puede activar un desvío que afecta transacciones financieras).
  • Los cambios de estado del Detour deben registrarse en el audit log.

17. Errores Comunes

Detour que Se Convierte en Permanente

El error más frecuente. Un Detour se activa "temporalmente" y nunca se desactiva porque nadie recuerda o se atreve. Mitigación: siempre programar una fecha de expiración y alertar cuando se aproxima.

No Probar la Ruta de Desvío

La ruta alternativa no se prueba regularmente y falla cuando se activa en producción. Mitigación: incluir la ruta de desvío en los tests de integración y ejecutar mensajes de prueba periódicamente contra ella.

Ignorar el Impacto en Latencia

El paso adicional del desvío puede añadir latencia significativa (especialmente si depende de un servicio externo). Si no se mide ni se monitorea, puede violar SLAs sin que nadie lo note. Mitigación: definir y monitorear SLAs para la ruta de desvío.

Múltiples Detours Encadenados

Varios Detours consecutivos en un flujo crean complejidad combinatoria (2^N rutas posibles). Mitigación: limitar el número de Detours por flujo y documentar las combinaciones válidas.

No Registrar en el Message History

Si el Message History no registra que el mensaje fue desviado, el diagnóstico posterior se dificulta: no se puede distinguir entre mensajes que tomaron la ruta directa y mensajes que pasaron por el desvío.

18. Conclusión Técnica

Detour es el patrón que introduce flexibilidad operacional controlada en los flujos de mensajería, permitiendo insertar y remover pasos de procesamiento dinámicamente sin alterar el diseño permanente del flujo. Es la materialización del principio de que la configuración operacional debe ser independiente del ciclo de despliegue.

Cuándo aporta valor: cuando existen necesidades recurrentes de pasos temporales en flujos de producción — auditorías periódicas, migraciones graduales, diagnósticos en producción, validaciones adicionales por demanda regulatoria. El valor se maximiza cuando la activación y desactivación debe ser inmediata y sin riesgo de despliegue.

Cuándo evita problemas importantes: Detour evita los ciclos de despliegue asociados a cambios temporales, que son costosos (en tiempo, riesgo y coordinación) y desproporcionados respecto a la naturaleza temporal del cambio. También evita la acumulación de código temporal "permanente" al proporcionar un mecanismo limpio de activación/desactivación.

Cuándo no conviene adoptarlo: cuando la necesidad de desvío es única e irrepetible, cuando el paso adicional es permanente (simplemente inclúyalo en el flujo), o cuando el sistema es lo suficientemente simple como para que un redespliegue sea rápido y sin riesgo.

Recomendación para arquitectos: use Detour con disciplina. Cada Detour debe tener un owner, una justificación documentada, una fecha de expiración y monitoreo activo. Implemente la ruta de desvío como un componente de primera clase (probado, monitorado, mantenido), no como un hack temporal. Y sobre todo, establezca un proceso para revisar y eliminar Detours que ya no son necesarios — los Detours zombi son deuda técnica silenciosa.