Patrón strangler fig: cómo reemplazar un sistema en producción

El patrón strangler fig es una forma de reemplazar un sistema en producción de manera gradual. Pones una capa de enrutamiento delante del sistema antiguo y construyes las nuevas piezas detrás de ella, una a la vez. Cuando cada pieza nueva está lista, le envías el tráfico y retiras el código antiguo a medida que deja de usarse. El producto nunca se detiene y no hay un único día de lanzamiento.

Usé este enfoque cuando lideré la migración completa de una plataforma que postula automáticamente a ofertas de empleo en nombre de sus usuarios. Toda su arquitectura pasó de un stack legado a uno nuevo mientras la gente seguía usándola todos los días. Este artículo explica cómo funciona el patrón, en el orden en que yo lo aplicaría, y dónde no encaja.

¿Qué es el patrón strangler fig y de dónde viene el nombre?

El nombre viene de los higos estranguladores (strangler figs), plantas de la selva tropical que crecen alrededor de un árbol huésped. Con los años, el higo construye su propia estructura alrededor del árbol hasta que el árbol original desaparece y el higo se sostiene por sí solo. Martin Fowler tomó prestada la imagen a principios de los años 2000 para describir la migración de software de la misma forma: hacer crecer el sistema nuevo alrededor del antiguo hasta que el antiguo se pueda eliminar.

El contraste es la reescritura big-bang. En una reescritura, un equipo construye el reemplazo en paralelo, normalmente durante meses, y luego hace el cambio en una sola fecha. Todo tiene que coincidir con el comportamiento antiguo ese día, incluido el comportamiento que nadie documentó. Las reescrituras tienden a costar más y tardar más que la migración incremental, porque el sistema antiguo tiene que seguir funcionando y cambiando mientras se construye el nuevo.

Con el enfoque strangler, mantienes el producto funcionando y lo migras pieza por pieza. Cada pieza es lo bastante pequeña como para probarla, lanzarla y revertirla por sí sola.

¿Cómo funciona el switch delante del sistema antiguo?

El switch es una capa de enrutamiento que se ubica entre los usuarios y tus sistemas. Todas las solicitudes pasan por ella. Su primera versión no hace nada ingenioso: reenvía el 100% del tráfico al sistema antiguo. Ese es el punto. Demuestras que la capa es segura antes de que asuma cualquier riesgo.

Ahí es donde empiezo, tanto en la migración de la plataforma de postulaciones como en cualquier sistema en producción que tomo a cargo. Antes de que exista el switch, cada cambio es una apuesta. Una vez que existe, cada cambio se puede deshacer.

Lo que el switch tiene que hacer

• Enrutar por ruta o funcionalidad. Por ejemplo, las solicitudes a un prefijo de URL o a un endpoint de API van al servicio nuevo, y todo lo demás va al antiguo.
• Enrutar por audiencia. Envía primero a los usuarios internos, luego a una pequeña parte de los usuarios reales y luego a todos. Aquí es donde entran los feature flags y los despliegues de estilo canario.
• Volver atrás al instante. El rollback debería ser un cambio de configuración, no un despliegue.
• Ser observable. Necesitas ver errores, latencia y resultados por ruta, separados entre lo antiguo y lo nuevo.

Qué puede ser

Depende de tu sistema:

• Un proxy inverso o un balanceador de carga funciona para aplicaciones web.
• Un API gateway funciona para backends basados en servicios.
• En un producto con mucho peso en el frontend, el switch puede vivir en la propia app, con flags que deciden qué implementación se renderiza.

Elige lo más simple que tu equipo ya sepa operar. El patrón no depende de una herramienta específica.

¿Cómo es una migración strangler fig real, paso a paso?

Esta es la secuencia que sigo. Los tiempos exactos varían según el sistema, así que no voy a ponerle fechas.

1. Consigue acceso y entiende lo que existe. Esto incluye repositorios, hosting, bases de datos, DNS y cuentas de terceros. No puedes enrutar tráfico que no controlas.
2. Divide el sistema en porciones. Enumera las funcionalidades de cara al usuario y los jobs en segundo plano. Cada porción debe tener una entrada y una salida claras, por ejemplo "login", "búsqueda" o "enviar notificación".
3. Instala el switch enviando todo al sistema antiguo. Lánzalo solo. Si algo se rompe, sabes que es la capa y nada más.
4. Agrega pruebas sobre el comportamiento actual. Antes de reemplazar una porción, registra lo que hace hoy, incluidas sus rarezas. Esas pruebas definen qué significa "terminado".
5. Construye la primera porción en el stack nuevo. Mantenla pequeña y de bajo riesgo.
6. Ejecútala en modo sombra si puedes. Envía copias de solicitudes reales al código nuevo y compara sus respuestas con las del antiguo. Todavía no muestres el resultado a los usuarios.
7. Libera de forma gradual. Empieza con los usuarios internos, luego una pequeña parte, luego más. Vigila las métricas en cada paso y ten el rollback listo.
8. Retira la porción antigua. Cuando pase un período razonable sin recibir tráfico, borra el código. Saltarte este paso te deja ejecutando dos sistemas para siempre.
9. Repite. Cada ciclo hace más fácil el siguiente, porque el switch, las pruebas y el monitoreo ya existen.

La cuestión de los datos atraviesa todos estos pasos, y es donde he visto que las migraciones se vuelven más difíciles. O ambos sistemas leen y escriben en la misma base de datos durante un tiempo, o sincronizas los datos entre ellos con algo como change data capture. Decídelo pronto, porque determina cómo divides el sistema.

¿Qué partes deberías migrar primero y cuáles al final?

El orden importa más que la velocidad. Las primeras porciones le enseñan a tu equipo cómo se comporta realmente el sistema antiguo, así que deberían tolerar errores. Cuando tomo a cargo una base de código, sigo un orden fijo: primero el acceso, luego el build, luego los flujos de dinero, luego los riesgos. El orden de migración de abajo sigue la misma lógica.

Por qué los flujos de dinero van después

Parte del código le cobra a un cliente o dispara una acción que no se puede deshacer. Ese código merece tu proceso más maduro. Para entonces ya tienes un switch que funciona, pruebas de comparación, dashboards y un rollback ensayado. Migrarlo primero significa aprender el patrón con tu código más riesgoso.

Hay un contrapeso. Si el mayor problema del sistema antiguo está en el núcleo, dejarlo para el final puede significar que la migración nunca se pague. En ese caso, empiezo por las piezas que rodean el núcleo. Lo achican y aclaran sus límites, y después abordo el núcleo con las mejores herramientas ya funcionando.

¿Cuándo el patrón strangler fig es la elección equivocada?

Es una buena opción por defecto, pero no universal. Si un sistema cae en uno de estos casos, prefiero decirlo desde el principio antes que forzar el patrón:

• No hay un punto de corte donde poner el switch. Algunas apps de escritorio, sistemas embebidos o monolitos muy acoplados no enrutan las solicitudes a través de nada que puedas interceptar. Puede que tengas que crear ese punto de corte primero, lo cual es un proyecto en sí mismo.
• El sistema es pequeño. Si todo se puede reconstruir y verificar en poco tiempo, ejecutar dos sistemas en paralelo agrega más sobrecarga de la que ahorra.
• La plataforma antigua se va a apagar de todos modos. Si el proveedor termina el soporte en una fecha fija, puede que necesites un camino más rápido y directo.
• Lo antiguo y lo nuevo necesitan modelos de datos incompatibles. Si mantener los datos sincronizados es más difícil que la propia migración, un cambio planificado con una ventana de mantenimiento puede ser la opción más sensata.
• El equipo no puede sostener dos sistemas. El patrón implica mantener ambos durante un tiempo. Si el equipo ya está al límite, el período de transición puede doler.

Ten en cuenta también lo que el patrón no resuelve. Si el problema es el producto en sí, una migración limpia solo te da el mismo producto en un stack más nuevo.

¿Cómo encaja en un plan más amplio de modernización de sistemas legados?

El patrón strangler fig es un método de entrega, no una estrategia. Antes de elegirlo, deberías saber tres cosas: por qué estás modernizando, qué hace el sistema actual y qué estás dispuesto a dejar atrás. Primero vienen una auditoría de código y una revisión de tu deuda técnica. Después vienen las decisiones entre replatforming, refactorización en el lugar o reemplazo.

Alrededor de la migración en sí, unas pocas prácticas de apoyo hacen la mayor parte del trabajo:

• Feature flags para controlar quién ve el camino nuevo.
• Despliegues canario o blue-green para reducir el riesgo de cada liberación.
• Un plan de migración de base de datos que cubra la sincronización, la validación y el cambio de los datos.
• Monitoreo que compare el comportamiento antiguo y el nuevo con números reales.

La regla que me llevo de la migración de la plataforma de postulaciones es simple: pon el switch delante de todo antes de escribir código nuevo. Una vez que los usuarios pasan por una capa que controlas, cada decisión posterior se vuelve más pequeña y reversible.

¿Estás planificando una migración?

Si estás evaluando este patrón para un sistema en producción, escríbeme a me@filipeeduardo.dev con una breve descripción del stack y de dónde te duele. Con gusto comparo notas contigo y te digo qué revisaría primero.