Software Architecture
Explica cómo migrar arquitecturas de forma incremental mediante Strangler Fig, seams, coexistencia, routing, sincronización, observabilidad y rollback.
Una migración arquitectónica no es solamente construir el sistema nuevo. Es transferir comportamiento, datos, tráfico y ownership mientras el negocio continúa operando y existe una ruta segura para detener, comparar o revertir.
Los cambios arquitectónicos grandes rara vez pueden realizarse en un único despliegue. Durante un periodo coexistirán:
estado actual
→ crear seam
→ coexistencia controlada
→ migrar capacidad y datos
→ verificar equivalencia
→ transferir ownership
→ retirar legadoEl éxito no consiste en que el sistema nuevo reciba tráfico. Consiste en que el camino anterior, las sincronizaciones temporales y el riesgo de volver atrás hayan sido eliminados de forma segura.
Una reescritura big bang concentra demasiadas incertidumbres:
Cuanto más tiempo se construye el reemplazo aislado, más diverge del sistema en producción. Al final, el equipo debe migrar todo de una vez y descubrir errores bajo máxima presión.
Una migración incremental divide el riesgo y produce evidencia antes de comprometer todo el sistema.
Qué reglas y funciones atiende cada camino.
Dónde está la fuente de verdad, cómo se sincroniza y cómo se verifican divergencias.
Qué clientes, tenants o porcentaje utilizan la nueva ruta.
Qué equipo y componente tiene autoridad para cambiar, operar y responder por la capacidad.
Migrar solo comportamiento sin ownership deja dos sistemas responsables. Migrar tráfico sin datos correctos produce respuestas divergentes.
El patrón Strangler Fig coloca una frontera alrededor del sistema existente y reemplaza capacidades de manera gradual.
clientes
↓
facade / router / API gateway
├── capacidad antigua → legado
└── capacidad migrada → sistema nuevoEl router puede decidir por:
La fachada no debe convertirse en un segundo legado lleno de lógica. Su responsabilidad temporal es enrutar, adaptar contratos y observar la transición.
Una buena primera extracción tiene:
Evita comenzar por el núcleo más interconectado solo porque parece importante.
Ejemplos iniciales razonables:
Una capacidad con invariantes distribuidas y muchas escrituras puede requerir preparar boundaries antes de extraer.
Antes de cambiar:
El legado suele contener reglas no documentadas. Algunas son bugs; otras representan necesidades reales.
El seam permite interceptar o sustituir comportamiento.
Puede ser:
Ejemplo:
antes:
OrdersController → LegacyInventoryDatabase
después:
OrdersController → InventoryPort → LegacyInventoryAdapterEste paso no cambia todavía el resultado. Centraliza el acceso para poder introducir el camino nuevo.
El sistema nuevo no necesita copiar internals del legado. Necesita mantener el comportamiento externo que todavía es requerido.
Define:
“Ambos devuelven JSON” no demuestra equivalencia.
La parte más difícil suele ser el ownership de datos.
Copia datos históricos al modelo nuevo.
Necesita:
Un backfill debe poder reanudarse sin duplicar ni reiniciar todo.
Captura cambios del sistema antiguo y los aplica al nuevo.
Ventajas:
Riesgos:
Una operación escribe ambos sistemas.
request
→ write antiguo
→ write nuevoEs peligroso si no existe coordinación. El primer write puede completar y el segundo fallar.
Alternativas:
Si se utiliza dual write temporal, deben existir estados de fallo y reparación.
Se consulta ambos caminos para comparar o fallback.
Problemas:
Es útil como herramienta temporal de validación, no como arquitectura permanente.
En cada fase debe existir una autoridad explícita.
fase 1: legado escribe, nuevo replica
fase 2: nuevo escribe, legado recibe compatibilidad
fase 3: nuevo es única autoridadNo declares “ambos son fuente de verdad”. Eso significa que los conflictos no tienen resolución definida.
Shadow traffic envía una copia de requests al camino nuevo sin utilizar su resultado para el usuario.
Permite comparar:
Debe evitar efectos duplicados. Es adecuado para lecturas o ejecución en modo dry-run. Para escrituras se necesita sandbox, simulación o deduplicación explícita.
La comparación debe considerar diferencias permitidas, como orden de campos o timestamps.
Opciones:
Cada fase necesita:
Aumentar tráfico automáticamente sin comprobar integridad puede propagar un fallo rápido.
Volver a la versión anterior del código no siempre restaura el estado.
Preguntas:
Diferencia:
En migraciones de datos, roll forward suele ser más seguro que intentar deshacer transformaciones complejas.
Es útil cuando el cambio ocurre dentro del mismo proceso.
Ejemplo:
interface SearchPort {
search(input: SearchInput): Promise<SearchResult[]>;
}El adapter antiguo usa SQL; el nuevo usa un índice de búsqueda. El dominio no conoce cuál está activo.
Añade el formato nuevo sin romper el anterior.
Actualiza escritores, lectores y datos.
Elimina el formato viejo cuando ninguna versión depende de él.
Ejemplo de rename de columna:
business_id junto a tenant_id.tenant_id.Situación actual: búsquedas SQL lentas y acopladas al catálogo.
Usar un motor de búsqueda derivado sin convertirlo en fuente de verdad.
ProductIndexed o cambios de catálogo.Este caso es más sencillo que migrar inventario porque el índice es derivado.
Más complejo porque existen escrituras e invariantes.
La fase de transferencia de autoridad debe estar claramente marcada.
Mide:
Una migración sin métricas puede quedar atascada durante años.
Cada fase necesita responsables:
Ownership temporal compartido debe tener fecha de finalización. Si nadie posee retirar el legado, la migración termina añadiendo otro sistema.
Antes de iniciar, define qué significa terminar:
Sin criterios, “temporal” se vuelve permanente.
El sistema nuevo evoluciona aislado y el cutover concentra todo el riesgo.
Dos autoridades producen divergencia y operación compleja.
No existe forma de saber si el resultado es correcto.
Ignora datos y efectos externos ya realizados.
Mover tablas o clases sin ownership conserva el acoplamiento mediante red.
Mientras existan fallback, sincronización y legado activo, la deuda continúa.
El equipo se mueve a otra prioridad y deja dos sistemas.
Conway, Team Topologies y arquitectura sociotécnica explica por qué las fronteras del sistema también dependen de comunicación, ownership y carga cognitiva de los equipos.