El patrón strangler fig para migraciones legacy
Los rewrites big-bang apuestan todo a una fecha. El patrón strangler fig gana enrutando tráfico endpoint por endpoint — construyendo el sistema nuevo alrededor del viejo hasta que el núcleo legacy queda hueco y es seguro retirarlo.
El rewrite llevaba dieciocho meses. Llegó la fecha de lanzamiento. El tráfico cambió. Tres semanas después, el tráfico volvió atrás. El sistema nuevo manejaba happy paths; los edge cases vivían solo en el codebase legacy que nadie había mapeado por completo. Integraciones de nómina, overrides de admin, códigos promocionales de diez años — la apuesta big-bang de que una fecha en el calendario podía reemplazar la verdad incremental. Strangler fig legacy migration hace la apuesta opuesta: enrutar una capacidad a la vez, probar cada slice en producción, mantener el rollback trivial hasta que el sistema viejo no tenga nada más que hacer.
El patrón nombra una higuera que crece alrededor de un árbol huésped, eventualmente reemplazándolo. En software: una fachada o router se sitúa delante del sistema legacy. Las implementaciones nuevas absorben endpoints, eventos o rutas de datos. El núcleo legacy se reduce hasta que el desmantelamiento es un proyecto pequeño, no un evento de riesgo para toda la empresa.
Los rewrites big-bang fallan ante unknown unknowns
| Riesgo big-bang | Por qué se compone |
|---|---|
| Reglas de negocio ocultas | Solo emergen bajo edge cases en producción |
| Desarrollo en paralelo | El legacy sigue cambiando durante el rewrite |
| Brechas en inventario de integraciones | Consumidores no documentados aparecen en el cutover |
| Rollback todo-o-nada | Revertir es tan arriesgado como el lanzamiento |
| Caída de moral | Largos períodos oscuros antes de validación |
Los rewrites se ven limpios en diagramas de arquitectura. Son desordenados en backlogs de tickets, SLAs de partners y auditorías de compliance. El strangler fig acepta el desorden de antemano — sistemas duales, complejidad de enrutamiento, duplicación temporal de datos — a cambio de entrega continua de valor y pasos reversibles.
Una migración sin rollback por paso es un rewrite con disfraz de plan de proyecto.
Anatomía de una migración strangler fig
Fachada / router. Punto de entrada único para clientes — API gateway, reverse proxy o router de aplicación. Todo el tráfico pasa por ahí. Las reglas de enrutamiento deciden implementación legacy vs nueva por endpoint, feature flag o tenant.
Selección de slice. Elegir límites con inputs y outputs claros — un recurso REST, un tipo de evento, un batch job. No "el módulo de facturación" — POST /invoices, evento InvoiceCreated, job nocturno de reconciliación.
Nueva implementación. Construir detrás de la fachada. Modo shadow opcional: el sistema nuevo procesa requests pero no responde a clientes — comparar outputs antes del cutover.
Cambio de tráfico. Por porcentaje, por tenant o cutover completo por slice. Los feature flags controlan el enrutamiento sin redesplegar la fachada.
Reducción del legacy. Eliminar código enrutado del legacy solo tras prueba sostenida — métricas en verde, sin rollback por N días, reconciliación limpia.
Desmantelamiento. Cuando el legacy maneja cero tráfico de producción y no hay dependencias batch, retirar infraestructura.
Clients → Facade/Router
├─ /users/* → New User Service
├─ /orders/* → New Order Service
├─ /reports/* → Legacy Monolith
└─ /admin/* → Legacy Monolith (last)
El artículo sobre arquitectura modular monolith para startups describe límites internos de módulos que se convierten en slices naturales de strangler — extraer un módulo a servicio sin reescribir toda la aplicación.
La migración de datos es la parte difícil que el enrutamiento no resuelve
Enrutar tráfico HTTP es la capa visible. Los datos suelen sobrevivir al código.
| Patrón de datos | Enfoque strangler |
|---|---|
| Slice read-heavy | El servicio nuevo lee réplica; el legacy sigue escribiendo hasta el cutover |
| Migración de escritura | Período dual-write — ambos sistemas aceptan escrituras, job de reconciliación compara |
| Sync event-driven | El legacy emite eventos de cambio; el sistema nuevo construye read model |
| Anti-patrón de base compartida | Extraer slice de schema a DB nueva con sync; último recurso son tablas compartidas con ownership estricto |
Los períodos dual-write necesitan reconciliación — comparar conteos de filas, checksums, diffs de muestra en schedule. Divergencia descubierta al desmantelar es cara. Divergencia descubierta cada noche es manejable.
Nunca eliminar rutas de datos legacy hasta que la ruta nueva haya procesado tráfico de producción a través de un ciclo de negocio completo — cierre de mes, ciclo de facturación, ventana de reporting de compliance.
Estrategia de orden de slices
No todos los endpoints son candidatos iguales de migración.
Migrar primero:
- Dominios de alto churn y bien entendidos con buena cobertura de tests
- Rutas read-heavy donde escrituras legacy obsoletas sean tolerables brevemente
- Features que bloquean la dirección de producto nueva
- Endpoints con pocos consumidores no documentados
Migrar al final:
- Rutas de admin y override con reglas de negocio implícitas
- Batch jobs con dependencias de calendario
- Integraciones con partners externos que requieren recertificación
- Áreas donde el "cómo funciona" vive en la cabeza de un solo ingeniero
Cada slice se envía de forma independiente. Celebrar la finalización de slices — no solo el desmantelamiento final. La moral sobrevive a la prueba incremental.
Operaciones de fachada: enrutamiento, observabilidad, rollback
La fachada es infraestructura de producción. Tratarla en consecuencia.
- Config de enrutamiento como código — reglas versionadas, cambios revisados, traza de auditoría.
- Métricas por ruta — latencia, tasa de error, reparto de tráfico legacy vs nuevo.
- Rollback instantáneo — cambiar flag o regla de enrutamiento a 100% legacy para un slice sin afectar otros.
- Trazado de requests — correlation ID a través de fachada hasta implementación; esencial para comparación en shadow mode.
Feature flags como infraestructura de release se solapan con el enrutamiento strangler — los flags controlan qué implementación sirve tráfico. La diferencia es intención estratégica: los flags compuertan features; los flags strangler compuertan reemplazo arquitectónico.
¿Cómo deberían los equipos planificar una migración strangler fig?
Estas preguntas evitan fachadas que se vuelven complejidad permanente.
¿Cuándo es strangler fig mejor que un rewrite?
Cuando el legacy está en producción con usuarios reales, reglas ocultas e integraciones que no pueden pausar. Cuando el equipo necesita enviar capacidades nuevas durante la migración. Cuando el rollback por slice es un requisito. El rewrite puede servir para reemplazo greenfield sin dependencia de producción — raro en sistemas maduros.
¿Qué tan pequeño debe ser un slice?
Lo bastante pequeño para rollback en un cambio de enrutamiento. Lo bastante grande para entregar valor significativo. Típico: un grupo de recursos API, un consumidor de eventos, un job programado — semanas a meses, no días ni años.
¿Qué impide que la fachada se vuelva permanente?
Rastrear porcentaje de tráfico legacy por ruta. Definir criterios de desmantelamiento de antemano: "tráfico legacy /orders = 0 por 30 días." Fachadas sin métricas de sunset se convierten en operaciones de sistemas duales para siempre.
Un argumento común va en la dirección opuesta
La visión opuesta sostiene que mantener dos sistemas cuesta más que un rewrite rápido — que strangler fig prolonga el dolor y duplica esfuerzo.
El costo de sistemas duales es real y debe presupuestarse. El costo de fallo big-bang — revertir, meses perdidos, impacto en clientes — es mayor y menos predecible. Strangler fig acota el downside por slice. El tiempo total en calendario puede superar un big-bang exitoso, pero los big-bangs que fallan no tienen tiempo total en calendario — tienen un reinicio.
Los equipos con capacidad limitada se benefician precisamente porque los slices caben en sprints normales junto con trabajo de features. Los rewrites consumen el roadmap.
Key takeaways
- Strangler fig migra un endpoint o capacidad a la vez detrás de un router fachada.
- Los rewrites big-bang fallan ante edge cases e integraciones descubiertas solo en el cutover.
- Dual-write de datos y reconciliación importan tanto como el enrutamiento de tráfico.
- Migrar primero slices read-heavy bien entendidos; admin y batch jobs al final.
- Rollback por slice vía flags de enrutamiento mantiene la migración reversible.
- Rastrear tráfico legacy por ruta — fachadas sin métricas de sunset se vuelven permanentes.
Conclusion
La migración legacy no es un proyecto con línea de meta en un Gantt. Es una secuencia de pequeñas pruebas de que el sistema nuevo puede cargar la verdad de producción — un slice a la vez, con el sistema viejo aún en pie hasta que cada prueba se sostenga.
El primer paso no es escribir código nuevo. Es inventario: listar cada entry point al sistema legacy, medir tráfico y riesgo por ruta, elegir el slice de mayor valor más pequeño y poner un router delante. La higuera crece desde ahí.