Strangler Fig

Reemplazar responsabilidad por incrementos

Strangler Fig permite reemplazar gradualmente comportamiento o responsabilidades de un sistema existente, introduciendo capacidad nueva alrededor de sus límites y trasladando hacia ella trabajo antes atendido por el camino anterior. Las partes desplazadas se retiran cuando dejan de ser necesarias. Dividir una reescritura en commits sin poner incrementos útiles en operación no produce ese resultado.

Martin Fowler publicó la metáfora en junio de 2004. Su texto original propone crecimiento alrededor del sistema y desplazamiento de funcionalidad mediante interceptación; la revisión de 2019 utiliza explícitamente pattern. Eso respalda kind: pattern en el Atlas. Original Strangler Fig Application.

La explicación actual, de agosto de 2024, enfatiza resultados, seams y modernización gradual. La imagen botánica es una higuera que crece alrededor de un árbol anfitrión hasta sostenerse por sí misma; orienta la analogía, sin imponer una topología informática literal. Fowler, Strangler Fig.

Es un mecanismo de transición, no un Architecture Profile ni una elección de destino. Puede apoyar evolutionary-architecture, pero aplicarlo no demuestra por sí solo cambio guiado con feedback y revisión de intención.

Qué se desplaza y por qué

El objeto del reemplazo puede ser un módulo, API, integración, ruta de UI, acceso a datos, subsistema o capacidad de negocio. No necesita ser un único monolito. Una transición puede conservar un modular-monolith, terminar en service-based-architecture o mantener otras fronteras justificadas.

Extraer servicios de un monolito puede utilizar Strangler Fig. Extraerlos sin reducir responsabilidad ni dependencias del sistema anterior puede dejar una distribución adicional del mismo problema. Ni cloud ni Microservices forman parte de la definición; tampoco existe una promesa de menor costo total que cualquier reescritura.

architectural-drivers debe explicar el cambio: soporte que termina, dificultad para modificar reglas, riesgo operacional o necesidad de entrega independiente. constraints puede exigir conservar disponibilidad, retención y compatibilidad. Un catálogo de destinos modernos no responde esas preguntas.

Encontrar un seam y dirigir trabajo

Un seam es un punto donde puede separarse o interceptarse una interacción. Antes de desviar una autorización hay que localizar quién la solicita, qué resultado interpreta y qué camino procesa reintentos. modularity facilita ese trabajo cuando existen fronteras significativas; crearlas puede ser parte de la intervención.

Reverse proxy, facade, gateway, adapter, flag o cambio de suscripción a eventos son mecanismos posibles. Una llamada local también puede dirigirse al reemplazo. La tecnología de routing implementa la decisión; no define el patrón. Interceptar eventos exige además precisar consumidores concurrentes, mensajes pendientes y momento efectivo del cambio.

La selección debe ser comprensible: por capacidad, endpoint, workflow, tenant, segmento de clientes o partición de datos. Elegir aleatoriamente cada intento de una misma operación puede enviar su continuación a un camino que desconoce el estado previo. Conviene explicar afinidad y continuidad del trabajo, además del porcentaje agregado.

Elegir un incremento útil

decomposition ayuda a identificar responsabilidades y granularity a examinar tamaño del cambio. Una porción demasiado amplia aumenta exposición al cutover; una demasiado pequeña puede multiplicar contratos y coordinación. No hay tamaño universal ni puntuación que sustituya conocimiento del dominio.

El siguiente recorrido es una ayuda de razonamiento del Atlas, no fases obligatorias de Fowler:

1. Precisar resultado, alcance y comportamiento que debe conservarse.
2. Localizar o crear un seam con límites conocidos.
3. Implementar el reemplazo y comprobar los casos relevantes.
4. Dirigir una población acotada y observar consecuencias.
5. Ampliar responsabilidad cuando la evidencia lo permita.
6. Retirar el camino desplazado y sus dependencias innecesarias.

Un resultado útil puede ser autorizar un subconjunto de pagos; no implica haber reemplazado refunds, conciliación o soporte histórico. La unidad migrada necesita una definición verificable para no confundir avance parcial con finalización.

Autoridad de datos durante la transición

data-migration desarrolla el movimiento y transformación de estado que puede acompañar este desplazamiento. Cambiar el routing dejando dependencias privadas de la base anterior puede mantener parte relevante de la migración abierta. El seam de ejecución no transfiere automáticamente autoridad ni elimina consumidores históricos.

Cambiar ejecución sin examinar información puede ocultar la dependencia principal. data-ownership pregunta quién es autoritativo ahora, quién escribe y cuándo cambia esa autoridad. Reemplazo y sistema anterior no deben convertirse silenciosamente en dos autoridades incompatibles sobre el mismo pago.

Payments v1 podría conservar escrituras mientras v2 consulta mediante contrato; más adelante podría transferirse responsabilidad para una población explícita. Otras variantes requieren réplicas, traducción o cutover de datos. Ninguna combinación es universal: hay que explicar qué copia representa qué hecho y cómo se detecta divergencia.

Dos escrituras independientes pueden fallar parcialmente, invertirse o repetirse. transactional-outbox relaciona un cambio local con publicación posterior; idempotency protege efectos repetidos bajo su contrato. No convierten cualquier dual write en una transacción distribuida ni resuelven automáticamente la reconciliación entre autoridades.

Si se mantiene una copia para el sistema anterior, definir frescura, acceso y duración. communication y coordination siguen importando: incorporar un evento o llamada remota no elimina quién decide ni qué estados intermedios observa cada participante.

Coexistencia, evidencia y recuperación

interfaces debe conservar significado para consumidores que migran en momentos distintos. parallel-change permite evolucionar formas del contrato durante esa ventana. interoperability examina intercambio e interpretación efectiva; traducir el payload sin conservar sus condiciones de uso puede romper el workflow.

La observación necesita distinguir camino, versión y población: quién procesó la solicitud, resultado final, latencia, errores, proporción de tráfico y uso de fallback. Una media global puede ocultar que la población nueva falla. Comparar resultados requiere declarar diferencias intencionales; repetir cobros reales para comparar implementaciones sería peligroso.

fitness-functions puede aportar evaluaciones sobre compatibilidad, ownership o resultados acordados. Son evidencia, no el mecanismo que mueve tráfico. También hay riesgos compartidos: dos caminos pueden usar la misma base, quota o runtime; isolation no se deduce de dibujar dos cajas.

Rollback de tráfico y reversibilidad del estado

Reducir tráfico al reemplazo puede contener exposición si el camino anterior todavía entiende el trabajo que recibirá. Eso no deshace pagos, eventos publicados ni transformaciones irreversibles. deployment y deployability requieren revisar código, datos y efectos conjuntamente.

En Commerce, v2 puede haber grabado una representación que v1 no interpreta. Volver a dirigir requests a v1 necesita entonces traducción, reconciliación o una corrección hacia adelante. Un porcentaje configurable no constituye por sí solo un plan de recuperación seguro.

También importa trabajo en vuelo. Una autorización aceptada por v2 puede terminar después del cambio de routing; un refund posterior puede necesitar consultar su procedencia. El registro de responsabilidad debe sobrevivir al cambio de versión. Conservar contratos de consulta puede ser necesario mientras se atienden obligaciones históricas.

Commerce: reemplazar Payments sin perder obligaciones

Las propiedades que preserva la transición deben declararse antes de ampliar exposición: órdenes aceptadas no perdidas, autoridad de pago inequívoca y consumidores soportados atendidos. Esas invariantes concretan restricciones del caso, no una nueva taxonomía. Si la población nueva cumple latencia pero pierde una autorización válida, el incremento no conserva el compromiso elegido. La revisión debe mirar ambas propiedades, no optimizar una a costa de la otra.

En este ejemplo propio, Commerce v1 contiene Orders, Payments, Inventory y Shipping. Un nuevo proveedor motiva Payments v2. Se seleccionan autorizaciones nuevas de una población identificable; refunds históricos continúan en v1 inicialmente.

Un seam dirige autorizaciones elegibles a v2 y conserva correlación con sus resultados. Orders solicita cambios mediante el contrato de Payments; no adquiere permiso para escribir sus tablas. Inventory mantiene vigencia de reservas y Shipping espera evidencia suficiente de confirmación, aunque el procesamiento atraviese versiones.

Si la autorización nueva funciona pero una devolución todavía depende de v1, la capacidad completa no terminó de migrar. Deben registrarse esas obligaciones y evaluar qué se necesita conservar antes de apagar el camino anterior. Una demostración exitosa del caso feliz no cubre historia ni excepciones.

Componer tres mecanismos

Esta es una síntesis del Atlas, no una metodología universal:

Preocupación en Commerce	Mecanismo posible
Trasladar responsabilidad de Payments v1 a v2.	Strangler Fig y selección explícita del trabajo.
Sustituir el motor dentro del límite de Payments.	branch-by-abstraction con implementaciones coexistentes.
Evolucionar PaymentAuthorized para consumidores existentes.	parallel-change y ventana de compatibilidad.
Contrastar invariantes de transición.	Fitness Functions y otra evidencia relevante.

Branch by Abstraction suele actuar sobre una implementación detrás de una abstracción; Strangler suele describir un desplazamiento más amplio de responsabilidad. Sus alcances pueden superponerse. Parallel Change se concentra en formas de contrato; ninguna de las tres técnicas sustituye decidir secuencia, recursos, dependencias y contingencias de migration-strategy. refactor-vs-rewrite conserva otra distinción: reimplementar una capacidad puede combinarse con introducirla incrementalmente mediante Strangler, sin exigir reemplazo big bang del producto.

Retirada, costo y criterio de terminación

Finalizar exige comprobar tráfico transferido, consumidores migrados, autoridad acordada, ausencia de usos antiguos y retiro de dependencias e infraestructura obsoletas. sunsetting desarrolla ese cierre con alcance y evidencia: retirar autorizaciones v1 puede conservar acceso a refunds e historia. deprecation puede preparar a consumidores antes del retiro; ninguno de esos conceptos equivale al mecanismo de desplazamiento de responsabilidad.

Cartwright, Horn y Lewis describen Transitional Architecture como elementos destinados a facilitar desplazamiento y retirarse después. Permite razonar sobre estados intermedios además del destino. Transitional Architecture. En nuestro caso puede incluir routing, adapters y copias temporales.

La coexistencia agrega operación, sincronización y carga cognitiva. Puede representar technical-debt deliberada con responsable, condición de retiro y observación. Una excepción prevista no constituye automáticamente architecture-erosion; perder su control y perpetuarla accidentalmente puede debilitar intención vigente.

legacy-systems hace visibles consumidores y conocimiento heredados; el mecanismo también sirve en sistemas recientes. systems-thinking obliga a considerar costos desplazados a otros equipos. Usarlo requiere una transición viable, no la expectativa de eliminar todo riesgo por cambiar gradualmente. evolution-and-modernization organiza las preguntas que acompañan esa decisión.