¿Base de datos antigua? Cómo adoptar el patrón Strangler Fig

El desafío de tocar una base de datos legada gigante

Toda empresa que crece acumula sistemas antiguos, conocidos popularmente como monolitos. En estos sistemas, una sola base de datos guarda el núcleo de funcionamiento de todo el negocio, mezclando tablas de clientes, pagos e inventario en una compleja red de dependencias. En la práctica, esto significa que alterar una simple columna puede derribar la aplicación entera, generando miedo y parálisis en el equipo de desarrollo.

Cuando la arquitectura necesita evolucionar hacia microservicios, que son pequeños servicios independientes enfocados en tareas específicas, la base de datos monolítica se convierte en el mayor obstáculo. Intentar reescribir todo de golpe es un error histórico que suele fracasar por exigir demasiado tiempo e interrumpir la entrega de valor al cliente. Es precisamente en este escenario crítico donde surge la necesidad de una estrategia incremental, permitiendo modernizar el ambiente sin detener la operación.

Qué es el patrón Strangler Fig y cómo funciona en la práctica

El concepto del Strangler Fig proviene de la naturaleza: la higuera estranguladora es una planta cuyas semillas germinan en las copas de árboles altos, creciendo al abrazar el tronco y enviando raíces al suelo hasta que el árbol original muere y la higuera ocupa su lugar. En la ingeniería de software, la idea es idéntica. En lugar de destruir el sistema antiguo, construimos una nueva estructura a su alrededor, reemplazando funcionalidades poco a poco.

Aplicando este concepto a las bases de datos, no migras todas las tablas en un solo fin de semana. Eliges un dominio aislado, como la gestión de clientes, y creas un nuevo microservicio con su propia base de datos optimizada. Tal como vimos al estructurar refactorizaciones en código legado confuso y refactorización incremental, la seguridad reside en pasos cortos, validados y continuos que protegen la integridad del sistema.

Estrategias de sincronización con replicación dual de datos

Durante la transición, la aplicación nueva y la antigua deben convivir y ver los mismos datos. El mayor desafío técnico de esta fase es la sincronización. Si un cliente actualiza su dirección en la nueva interfaz, ese cambio debe reflejarse inmediatamente en la base de datos legada; de lo contrario, otras partes de la empresa que dependen del sistema antiguo fallarán.

Un enfoque común para resolver este dilema es la replicación dual, donde la aplicación escribe tanto en la base de datos antigua como en la nueva durante un periodo de transición. Sin embargo, escribir en dos lugares distintos abre margen para fallas de consistencia cuando una operación falla. Para mitigar este riesgo de cuellos de botella operativos y garantizar estabilidad, muchos ingenieros combinan este enfoque con técnicas de resiliencia similares a las aplicadas al gestionar fallas de red y resolver inestabilidades de API en Node.js con circuit breaker.

Cómo usar el patrón Outbox para garantizar consistencia transaccional

Cuando dos bases de datos deben mantenerse sincronizadas, las transacciones distribuidas basadas en protocolos de confirmación en dos fases suelen ser lentas y propensas a bloqueos. Una alternativa elegante y muy adoptada en arquitecturas modernas es el patrón Transactional Outbox, que utiliza una tabla auxiliar en la base de datos para registrar eventos de cambio.

En la práctica, cuando se inserta o modifica una fila en la base de datos legada, la aplicación escribe un evento correspondiente en una tabla de salida (outbox) dentro de la misma transacción de la base de datos. Un proceso secundario, llamado publisher, lee esta tabla de salida y despacha los mensajes a un bus de eventos o directamente al nuevo microservicio. Esto garantiza que no se pierda ningún dato, incluso si la red falla momentáneamente o el microservicio no está disponible.

Enrutamiento inteligente de tráfico entre el monolito y el microservicio

Con los datos sincronizados, el siguiente paso es decidir quién atiende cada solicitud de los usuarios. El enrutamiento de tráfico actúa como un portero inteligente en la entrada de la aplicación, implementado generalmente mediante un API Gateway o reglas configuradas en un proxy inverso como Nginx o Caddy.

Al principio, el cien por ciento de las llamadas de lectura y escritura van al monolito. A medida que el nuevo microservicio gana madurez y estabilidad en producción, el enrutamiento comienza a dirigir pequeños porcentajes de tráfico a la nueva API — por ejemplo, el diez por ciento de los usuarios pasan a usar el nuevo servicio de perfiles. Si ocurre cualquier comportamiento anómalo o lentitud severa comparable a los problemas descritos en cómo hallar cuellos de botella de IOPS de disco en Linux, el tráfico puede revertirse instantáneamente al monolito sin impacto perceptible.

Identificando y eliminando código y tablas huérfanas de forma segura

El ciclo del Strangler Fig solo se completa cuando el código y las tablas antiguas se borran por completo del monolito. Sin embargo, el miedo de que alguna funcionalidad oculta siga dependiendo de esa estructura legada paraliza a muchos desarrolladores a la hora de la limpieza final.

Para realizar esta limpieza con seguridad, utiliza registros de auditoría y métricas de acceso a la base de datos para rastrear si alguna consulta sigue tocando las tablas legadas. Monitorea el comportamiento del sistema durante varias semanas de operación normal antes de ejecutar la eliminación definitiva. Esta disciplina evita sorpresas desagradables en producción y consolida la independencia del nuevo microservicio.

Consideraciones finales sobre la migración incremental de bases de datos

Adoptar el patrón Strangler Fig requiere paciencia, planificación rigurosa y madurez cultural del equipo de ingeniería. La migración deja de ser un evento estresante de cambio masivo y se convierte en una evolución continua de la arquitectura. Al desacoplar bases de datos de forma gradual, tu empresa gana velocidad de entrega, resiliencia operativa y la libertad de escalar servicios de manera independiente según la demanda del negocio.