Una organización operaba una plataforma web heredada conectada a procesos centrales. Reemplazarla de una sola vez habría concentrado demasiado riesgo técnico y operativo.
La situación #
La arquitectura objetivo no era la parte difícil. El reto era diseñar una transición en la que el sistema anterior y las nuevas capacidades pudieran coexistir sin perder ownership de datos, trazabilidad ni una ruta de regreso.
Lo que estaba en juego #
- Interrumpir procesos centrales durante el cambio.
- Crear escrituras concurrentes o estados contradictorios.
- Mover tráfico sin criterios claros de abort y rollback.
- Construir servicios nuevos sin visibilidad de punta a punta.
Mi responsabilidad #
Como principal architect y advisor, diseñé la dirección objetivo y la ruta de transición por capacidades. Definí límites, contratos, ownership de escritura, enrutamiento gradual, criterios de liberación y necesidades de observabilidad entre componentes heredados y nuevos.
Decisiones clave #
- Aplicar un patrón strangler por capacidad, no por capa técnica.
- Mantener un solo writer para cada dominio durante la transición.
- Estabilizar contratos antes de sumar consumidores.
- Mover tráfico con canary, criterios de abort y rollback.
- Observar cada journey cruzando ambos lados de la arquitectura.
Resultado defendible #
Quedaron definidas una arquitectura objetivo y una ruta de transición por fases, con ownership, contratos, controles de liberación y reversibilidad explícitos.
Límites #
La implementación fue parcial y por fases. No se afirma que el sistema heredado haya sido retirado, que la sustitución total se haya completado ni que existan métricas públicas de impacto.