Patrón de la higuera estranguladora: una guía pragmática para líderes de ingeniería

El patrón de la higuera estranguladora, acuñado por Martin Fowler, es un enfoque arquitectónico para reemplazar gradualmente la funcionalidad de un sistema heredado mediante una fachada o un proxy que dirige el tráfico a nuevos componentes hasta que el sistema antiguo pueda retirarse de forma segura. El nombre proviene del árbol de la higuera estranguladora, que crece alrededor de un árbol anfitrión y lo va sustituyendo gradualmente hasta que el anfitrión original desaparece. En software, el mecanismo es el mismo: envolver, redirigir, reemplazar y retirar.

Tres conceptos sustentan el patrón: una fachada que intercepta todo el tráfico, la extracción incremental de funcionalidades hacia nuevos servicios y una puerta de retirada que confirma que el sistema heredado ya no es necesario. Úsalo cuando:

• Una reescritura completa conlleva un riesgo de entrega o empresarial inaceptable

• El sistema debe seguir atendiendo el tráfico de producción durante toda la migración

• La entrega de funcionalidades no puede detenerse durante meses mientras se completa una reescritura

• El Azure Architecture Center y AWS Prescriptive Guidance lo recomiendan para la migración por fases de aplicaciones monolíticas a la nube

Ridiculous Engineering aplica este patrón en proyectos de modernización en los que el coste de equivocarse es alto y la tolerancia al tiempo de inactividad es baja.

Índice

• Por qué los equipos eligen el patrón de la higuera estranguladora en lugar de una reescritura completa

• Cómo funciona el patrón de la higuera estranguladora a nivel arquitectónico

• Técnicas y componentes concretos de implementación

• Guía por fases, desde el descubrimiento hasta la retirada

• Cómo es una migración real: el servicio de pedidos

• Compensaciones, dificultades y cuándo no usar este patrón

• Ridiculous Engineering ejecuta migraciones con el patrón de la higuera estranguladora de principio a fin

• Conclusiones clave

• Fuentes útiles y lecturas adicionales

• Preguntas frecuentes

Por qué los equipos eligen el patrón de la higuera estranguladora en lugar de una reescritura completa

Los sistemas heredados fallan para los equipos de formas predecibles. El código es frágil, la cobertura de pruebas es escasa y los ingenieros que entendían el diseño original ya se han marchado. Una reescritura completa parece atractiva hasta que llega la primera estimación y la empresa se da cuenta de que implica entre seis y dieciocho meses de inversión paralela sin entregar ninguna funcionalidad nueva.

Los problemas concretos que llevan a los equipos hacia la modernización incremental:

• Monolitos frágiles donde un cambio en un módulo rompe funcionalidades no relacionadas

• Lagunas de conocimiento en lenguajes antiguos (COBOL, PowerBuilder, primeras versiones de Java EE) que hacen que una refactorización segura sea casi imposible

• Restricciones normativas y de disponibilidad que prohíben ventanas de mantenimiento prolongadas

• Requisitos de entrega continua cuando las hojas de ruta de producto no pueden detenerse para una reescritura

• Riesgo de coste y tiempo en reescrituras grandes, que con frecuencia superan las previsiones presupuestarias por un margen considerable

La formulación original de Martin Fowler capta bien la disyuntiva principal:

La reducción del riesgo es el principal motor empresarial. El enfoque recomendado por Fowler prioriza los beneficios constantes y visibles por encima de un único lanzamiento. Para un CTO que defiende un presupuesto de modernización ante el consejo de administración, «hemos lanzado tres funcionalidades nuevas este trimestre mientras migrábamos el servicio de pedidos» es una conversación mucho más fácil que «tendremos algo que enseñarle en el cuarto trimestre del año que viene».

Cómo funciona el patrón de la higuera estranguladora a nivel arquitectónico

La arquitectura es conceptualmente sencilla. Cada solicitud del cliente pasa por una fachada estranguladora, que normalmente es una puerta de enlace de API, un proxy inverso o una capa de enrutamiento diseñada específicamente. La fachada inspecciona cada solicitud y la dirige al sistema heredado o al nuevo servicio, según qué funcionalidades se hayan migrado.

El flujo es el siguiente: cliente → fachada estranguladora → monolito heredado (para funcionalidades no migradas) o microservicio nuevo (para funcionalidades migradas). El sistema heredado y los nuevos servicios coexisten durante el periodo de migración. Nada cambia en el cliente.

Responsabilidades principales de la fachada:

• Enrutamiento de solicitudes según la ruta, la cabecera, el inquilino o el indicador de funcionalidad

• Capa anticorrupción (ACL) traducción entre los modelos de datos heredados y los contratos de los nuevos servicios, tal como documenta Azure Architecture Center

• Telemetría y registro de uso para medir qué puntos finales heredados siguen activos

• Enrutamiento A/B y canario para transferir gradualmente porcentajes de tráfico a los nuevos servicios

La entrada de Wikipedia sobre el patrón señala que se aplica a múltiples niveles de granularidad, desde envolver un único método hasta migrar una aplicación completa. Esa flexibilidad es lo que lo hace práctico: no es necesario comprometerse con una arquitectura completa de microservicios desde el primer día.

Consejo profesional: Instrumenta la fachada antes de extraer una sola funcionalidad. La telemetría de uso de la primera semana te indicará qué puntos finales se llaman con mayor frecuencia, cuáles utiliza un solo cliente y cuáles no se han utilizado en meses. Esos datos determinan tu lista de prioridades de extracción y a menudo revelan código obsoleto que simplemente puedes eliminar.

Técnicas y componentes concretos de implementación

Poner en marcha la fachada es la parte fácil. La complejidad de ingeniería reside en la lógica de enrutamiento, la sincronización de datos y mantener la coherencia del comportamiento de ambos sistemas durante la coexistencia.

Componentes principales

1. Fachada estranguladora (puerta de enlace de API o proxy inverso): NGINX, AWS API Gateway, Azure API Management o un servicio de enrutamiento personalizado. Es el único punto de entrada para todo el tráfico.

2. Capa anticorrupción (ACL): Una capa de traducción que convierte los modelos de datos y la semántica heredados en el modelo de dominio del nuevo servicio. Diseña las ACL con reglas de traducción explícitas y un plan de retirada desde el principio.

3. Adaptadores de servicio:Envoltorios delgados que permiten al nuevo servicio llamar a API o bases de datos heredadas sin importar la lógica heredada.

4. Indicadores de funcionalidad:Interruptores de ejecución (LaunchDarkly, Unleash o un almacén de indicadores propio) que controlan qué usuarios o inquilinos se enrutan al nuevo servicio.

5. Puntos de interceptación:Ganchos dentro del monolito que permiten a la fachada capturar eventos o cambios de datos sin modificar la lógica heredada principal.

Técnicas de enrutamiento

• Enrutamiento basado en rutas:Enrutar /orders/v2/* al nuevo servicio, /orders/* al sistema heredado.

• Enrutamiento por encabezado o inquilino:Enrutar determinados inquilinos o clientes de API al nuevo servicio para las pruebas con usuarios pioneros.

• Enrutamiento basado en indicadores de funcionalidad:Desviar gradualmente un porcentaje del tráfico (1 %, 10 %, 50 %, 100 %) mediante un almacén de indicadores.

• Lanzamientos canario:Enrutar una pequeña parte del tráfico de producción al nuevo servicio y comparar las tasas de error y la latencia antes de ampliar el despliegue.

Migración y sincronización de datos

Los datos son el aspecto que más suele ralentizar las migraciones de tipo estrangulador. Las opciones, aproximadamente en orden de complejidad, son:

• Escritura dual:La aplicación escribe simultáneamente en la base de datos heredada y en el nuevo almacén de datos. Es sencillo de implementar, pero los fallos de escritura requieren una lógica de conciliación cuidadosa.

• Captura de datos modificados (CDC):Herramientas como Debezium transmiten cambios a nivel de fila desde la base de datos heredada al nuevo servicio casi en tiempo real. Se recomienda CDC para sistemas con muchas escrituras, donde la latencia de la escritura dual resulta inaceptable.

• Abastecimiento de eventos:Reproducir eventos de dominio para reconstruir el estado en el nuevo servicio. Es potente, pero requiere que el sistema heredado emita eventos limpios.

• Relleno masivo:Migración puntual de datos históricos, normalmente ejecutada antes de la puesta en producción y conciliada con los deltas de CDC.

Consejo profesional: Para las rutas de lectura no críticas, la consistencia eventual suele ser aceptable. Reserve la complejidad de la escritura dual síncrona para las transacciones financieras, los recuentos de inventario y cualquier dato en el que una lectura obsoleta tenga una consecuencia empresarial real.

Lista de comprobación de pruebas y supervisión

• Pruebas de extremo a extremo que ejerciten tanto las rutas de código heredadas como las nuevas a través de la fachada

• Pruebas de contrato entre la fachada y cada servicio descendente

• Paneles de control de lanzamientos canario que registren la tasa de errores, la latencia p95 y la paridad de las métricas empresariales

• Alertas sobre desviaciones de comportamiento: si el nuevo servicio devuelve resultados diferentes de los del sistema heredado para la misma entrada, querrá saberlo antes que los usuarios

Guía por fases desde el descubrimiento hasta la retirada

Fase	Actividades principales	Funciones	Criterio de éxito
1. Descubrimiento	Inventariar los endpoints, mapear las dependencias e instrumentar la telemetría	Arquitecto, ingeniero de datos	Mapa de dependencias completo; identificados los 10 endpoints principales por volumen de llamadas
2. Identificar puntos de separación	Definir los límites de los servicios e identificar los puntos de traducción de la ACL	Arquitecto, propietario del producto	Contextos delimitados documentados; esquema de la ACL redactado
3. Crear la fachada y la ACL	Desplegar la capa de enrutamiento, implementar la ACL y validar la paridad	Arquitecto, SRE	El 100 % del tráfico fluye a través de la fachada sin regresiones
4. Extraer la primera funcionalidad	Migrar un endpoint de bajo riesgo y alto valor al nuevo servicio	Equipo de ingeniería, control de calidad	El nuevo servicio gestiona el endpoint objetivo; la tasa de errores coincide con la línea base del sistema heredado
5. Enrutar y supervisar	Desviar el tráfico de forma incremental mediante indicadores de funcionalidad y un despliegue canario	SRE, responsable de la migración	La latencia p95 se mantiene dentro del 10 % de la del sistema heredado; cero alertas de inconsistencia de datos
6. Iterar y escalar	Repetir la extracción para las funcionalidades restantes en orden de prioridad	Todo el equipo	Cada funcionalidad extraída supera las pruebas de contrato y el criterio de aprobación del despliegue canario
Retirar el sistema heredado	Confirmar que no haya llamadas entrantes, transferir la propiedad de los datos y archivar	Arquitecto, ingeniero de datos, SRE	No hay tráfico hacia el sistema heredado durante 30 días consecutivos; la paridad de datos está confirmada; el plan de reversión está documentado

Conviene hacer hincapié en el criterio de retirada. Un módulo heredado no está listo para retirarse hasta que se cumplen tres condiciones: que no haya llamadas entrantes durante un periodo definido (30 días es un mínimo razonable), que se haya confirmado la transferencia de la propiedad de los datos al nuevo servicio y que los datos históricos se hayan archivado o migrado con una ruta de lectura verificada. Omitir cualquiera de estas condiciones genera el peor resultado: un sistema «retirado» que, silenciosamente, sigue atendiendo tráfico.

En cuanto a las expectativas de calendario, un alcance pequeño suele durar unos meses, un alcance mediano, como un dominio completo, tarda menos de un año, y un alcance grande que implique la descomposición completa del monolito es un programa de varios años, como reconoce explícitamente la guía de Fowler.

Cómo es una migración real: el servicio de pedidos

Un punto de partida habitual para las migraciones de tipo estrangulador es el servicio de pedidos de un monolito minorista o SaaS. Esta es la secuencia de migración:

• Paso 1 — Extraer el modelo de lectura: Crear un nuevo microservicio de consulta de pedidos que lea de una copia replicada de la tabla de pedidos heredada. Enrutar todas las solicitudes GET /orders/* a través de la fachada hacia el nuevo servicio. El sistema heredado gestiona todas las escrituras.

• Paso 2 — Añadir el enrutamiento de fachada para los endpoints de pedidos: Desplegar la fachada de la pasarela de API. Confirmar que el 100 % del tráfico de pedidos fluye a través de ella sin regresión de latencia.

• Paso 3 — Implementar la ACL: Es probable que el modelo de pedidos heredado tenga campos desnormalizados, códigos de estado como enteros e identificadores de cliente que se correspondan con un esquema diferente. La ACL traduce estos elementos antes de que el nuevo servicio llegue a verlos.

• Paso 4 — Migrar los flujos de escritura con CDC: Configura Debezium (o una herramienta equivalente) para transmitir las escrituras de pedidos desde la base de datos heredada al registro de eventos del nuevo servicio. Valida la paridad de los datos entre ambos almacenes.

• Paso 5 — Validar y realizar un despliegue canario: Dirige el 5 % del tráfico de escritura al nuevo servicio. Supervisa las discrepancias en el número de pedidos, las transiciones de estado fallidas y los fallos de las notificaciones posteriores.

• Paso 6 — Completar el cambio y retirar el sistema antiguo: Dirige el 100 % del tráfico al nuevo servicio. Supervisa durante 30 días. Retira las tablas de pedidos heredadas después de confirmar que no existen lecturas directas.

La arquitectura durante la coexistencia: cliente → fachada de la puerta de enlace de API → monolito heredado (escrituras, inicialmente) y nuevo microservicio de pedidos (lecturas y, después, escrituras). Ambos servicios comparten un flujo de replicación CDC durante la transición. Los diagramas descargables del Azure Architecture Center ilustran claramente este enrutamiento por fases.

Fase de migración	Gestiona el sistema heredado	Gestiona el nuevo servicio	Comprobación de validación
Extracción de lecturas	Todas las escrituras, todas las lecturas	Lecturas de pedidos (GET)	Paridad de los datos en los resultados de lectura
Migración de escrituras (canario)	95 % de las escrituras	5 % de las escrituras	Tasa de errores, paridad del número de pedidos
Cambio completo	Nada	Todo el tráfico de pedidos	Confirmación de tráfico cero durante 30 días
Retirada	Archivado	Todo el tráfico de pedidos	Propiedad de los datos transferida

Consejo profesional: Consulta la lista de comprobación de migración empresarial para cualquier endpoint orientado al cliente que afecte al SEO o a las URL públicas. Una migración de tipo estrangulador que cambie las estructuras de las URL sin redirecciones adecuadas puede dañar el tráfico orgánico tanto como una reescritura mal ejecutada.

Compensaciones, dificultades y cuándo no utilizar este patrón

El patrón de la higuera estranguladora no siempre es la opción adecuada. Si se utiliza sin cuidado, crea su propia clase de problemas.

Riesgos y mitigaciones:

• Complejidad del enrutamiento: La fachada se convierte en una dependencia crítica de la ruta. Mitígala con interruptores de circuito, comprobaciones de estado y un fallback probado al sistema heredado para cada ruta.

• Problemas de coherencia de los datos: Tanto la escritura dual como CDC introducen periodos de incoherencia. Los equipos suelen subestimar el esfuerzo de ingeniería necesario para mantener las bases de datos sincronizadas.

• La fachada como cuello de botella: Una puerta de enlace de API con un dimensionamiento deficiente añade latencia a cada solicitud. Prueba el rendimiento de la fachada con carga de producción antes de dirigir tráfico real.

• Costes de coexistencia prolongada: Ejecutar dos sistemas en paralelo duplica la sobrecarga operativa. Presupuéstalo explícitamente; es posible que algunos módulos heredados nunca justifiquen una migración completa y deban aislarse detrás de la fachada indefinidamente.

• Acoplamiento oculto: Los sistemas heredados suelen tener efectos secundarios no documentados (disparadores de auditoría, trabajos por lotes, integraciones posteriores) que solo salen a la luz después de la extracción. Una fase de descubrimiento exhaustiva detecta la mayoría de ellos.

Lista de comprobación rápida para decidir: usa el patrón de la higuera estranguladora cuando:

1. El sistema debe permanecer activo durante toda la migración (sin ventanas de mantenimiento)

2. Una reescritura de golpe llevaría más de 6 meses y bloquearía la entrega de funcionalidades

3. Puedes definir límites de servicio o puntos de separación claros en la base de código existente

4. El equipo tiene capacidad para operar dos sistemas en paralelo

5. La complejidad de la migración de datos es manejable con CDC o escritura dual

No lo uses cuando:

1. El sistema heredado no tiene puntos de separación identificables (una auténtica «gran bola de barro» sin límites de dominio)

2. El equipo carece de capacidad de SRE para supervisar dos sistemas simultáneamente

3. El alcance de la migración es tan reducido (un único microservicio con API limpias) que una sustitución directa presenta menos riesgo

4. Las restricciones normativas prohíben ejecutar los sistemas heredado y nuevo en paralelo

Para los equipos que afrontan la integración de sistemas heredados de forma más general, el patrón es una herramienta dentro de un conjunto más amplio de modernización, no una respuesta universal.

Ridiculous Engineering ejecuta migraciones con el patrón de la higuera estranguladora de principio a fin

La mayoría de los equipos tiene la intención de modernizar de forma incremental. Son menos los que cuentan con la experiencia arquitectónica, la profundidad en ingeniería de datos y la capacidad de SRE necesarias para ejecutarlo sin que la migración se prolongue durante años o sin que la fachada se convierta silenciosamente en el nuevo sistema heredado.

Ridiculous Engineering’s desarrollo de software personalizadorealiza proyectos de migración progresiva con el patrón Strangler Fig, desde el descubrimiento hasta la retirada: mapeo de dependencias, diseño de fachadas y ACL, configuración de canalizaciones CDC, gestión del despliegue canario y asistencia a largo plazo una vez que los nuevos servicios están operativos. Aplicamos criterios medibles en cada fase para que sepa exactamente cuándo una funcionalidad está lista para la transición y cuándo es seguro retirar el módulo heredado. Si tiene un monolito que necesita migrar y una empresa que no puede detenerse durante el proceso, programe un proyecto de descubrimiento con nuestro equipo.

Conclusiones clave

El patrón de la higuera estranguladora es la opción adecuada cuando una reescritura de golpe es demasiado arriesgada, el sistema debe permanecer activo y puedes definir puntos de separación claros en la base de código existente.

Punto	Detalles
Instrumenta antes de extraer	Despliega primero la fachada y añade telemetría; los datos de uso determinan la prioridad de extracción.
Las ACL evitan la contaminación heredada	Diseña capas anticorrupción con reglas de traducción explícitas y un plan de retirada desde el primer día.
La sincronización de datos es la parte difícil	La replicación basada en CDC gestiona sistemas con muchas escrituras; la escritura dual se adapta a flujos más sencillos, pero requiere lógica de conciliación.
La retirada tiene un criterio estricto	No debe haber tráfico heredado durante 30 días consecutivos y debe confirmarse la paridad de datos antes de retirar cualquier módulo.
Ridiculous Engineering	Ejecuta proyectos con el patrón de la higuera estranguladora de principio a fin, con hitos de fase medibles, diseño de ACL y configuración de canalizaciones de CDC.

Fuentes útiles y lecturas adicionales

• Martin Fowler — StranglerFigApplication: El origen del patrón, la metáfora y la justificación fundamental de reducción del riesgo. Empieza aquí.

• Centro de arquitectura de Azure — Patrón de la higuera estranguladora: Diagramas de enrutamiento por fases, directrices sobre ACL y consideraciones de implementación del equipo de arquitectura de la nube de Microsoft.

• Orientación prescriptiva de AWS — Higuera estranguladora: Casos de uso de enrutamiento y ACL con notas de implementación nativa de la nube; cubre enfoques de escritura dual y CDC.

• Wikipedia — Patrón de la higuera estranguladora: Referencia concisa que aborda las opciones de granularidad y el registro de uso como herramienta de migración.

• Ridiculous Engineering — Integración de sistemas heredados: Patrones prácticos para una modernización no disruptiva del equipo de Ridiculous Engineering.

• Ridiculous Engineering — Costes de modernización de COBOL: Lecciones sobre presupuesto y plazos de proyectos de modernización de lenguajes heredados.

Preguntas frecuentes

¿Qué es el patrón de la higuera estranguladora en arquitectura de software?

El patrón de la higuera estranguladora es un enfoque para sustituir gradualmente un sistema heredado mediante el enrutamiento del tráfico a través de una fachada hacia nuevos servicios, una funcionalidad cada vez, hasta poder retirar el sistema heredado. Martin Fowler acuñó el término inspirándose en la biología de la higuera estranguladora.

¿En qué se diferencia el patrón de la higuera estranguladora de una reescritura de golpe?

Una reescritura de golpe sustituye todo el sistema de una vez, bloquea la entrega de funcionalidades y concentra todo el riesgo en un único lanzamiento. El enfoque de la higuera estranguladora migra una funcionalidad cada vez, entrega valor de forma continua y permite revertir los cambios en cualquier etapa.

¿Qué es una capa anticorrupción y por qué es importante?

Una capa anticorrupción (ACL) es un componente de traducción que convierte los modelos de datos y la semántica heredados en el modelo de dominio del nuevo servicio, evitando que las decisiones de diseño heredadas se filtren al nuevo sistema. Sin ella, los nuevos servicios tienden a heredar los mismos problemas estructurales que el sistema al que sustituyen.

¿Cuánto suele durar una migración con el patrón de la higuera estranguladora?

El plazo depende del alcance: una migración pequeña suele durar unos meses, un dominio completo, como un servicio de pedidos, puede durar menos de un año, y la descomposición de un monolito completo es un programa prolongado de varios años.

¿Cuándo no se debe utilizar el patrón de la higuera estranguladora?

Evítalo cuando el sistema heredado no tenga puntos de separación identificables, cuando el equipo carezca de capacidad de SRE para ejecutar dos sistemas en paralelo o cuando el alcance de la migración sea lo bastante pequeño como para que una sustitución directa conlleve menos riesgo que crear y mantener una fachada.

Recomendado

• Programación por intuición: ¿lo estamos haciendo mal? | Ridiculous Engineering

• Cómo la IA está transformando la cultura de ingeniería y el crecimiento profesional | Ridiculous Engineering

• La tecnología recurre a las habilidades analíticas para reforzar su plantilla | Ridiculous Engineering

• Desbloquear la creatividad con la teoría de las restricciones | Ridiculous Engineering