Del monolito a microservicios en fintech: cuándo y cómo migrar

Introducción

La decisión de migrar de una arquitectura monolítica a una basada en microservicios es una de las más importantes —y potencialmente costosas— que puede tomar una empresa fintech. Mientras que los microservicios ofrecen beneficios claros en escalabilidad, independencia de despliegue y resiliencia, también introducen complejidad operativa significativa. En este artículo analizamos cuándo tiene sentido hacer la migración, cuándo no, y cómo ejecutarla de forma incremental utilizando el patrón Strangler Fig aplicado específicamente al dominio de crédito.

El monolito: no siempre es el villano

Antes de hablar de migración, es importante reconocer que un monolito bien diseñado tiene ventajas reales:

Simplicidad operativa: un solo artefacto de despliegue, una sola base de datos, un solo proceso de monitoreo
Consistencia transaccional: las operaciones que abarcan múltiples dominios (crear crédito + generar amortización + registrar garantía) se ejecutan en una sola transacción de base de datos
Velocidad de desarrollo inicial: sin la sobrecarga de comunicación entre servicios, el equipo puede moverse rápido
Menor costo de infraestructura: un solo servidor o contenedor, sin necesidad de service mesh, API gateway o message broker

Para una fintech en etapa temprana (menos de 10 desarrolladores, producto en validación, menos de 1.000 créditos activos), el monolito es generalmente la arquitectura correcta.

Cuándo NO migrar

La migración a microservicios no es recomendable cuando:

El equipo es pequeño (menos de 5-8 desarrolladores): la sobrecarga operativa supera los beneficios
Los límites del dominio no están claros: si no se puede definir con precisión dónde termina originación y empieza cartera, la descomposición será incorrecta
El producto aún está en definición: cambios frecuentes en el modelo de negocio son más fáciles de implementar en un monolito
No hay problemas reales de escalabilidad: migrar por moda tecnológica, sin un problema concreto que resolver, introduce complejidad innecesaria
No se tiene experiencia operativa: operar microservicios requiere conocimientos de orquestación de contenedores, observabilidad distribuida y gestión de fallos

Cuándo SÍ migrar

La migración se justifica cuando aparecen señales concretas:

Conflictos de despliegue: múltiples equipos necesitan desplegar al mismo tiempo y los cambios se bloquean entre sí
Escalabilidad diferencial: el módulo de causación necesita más recursos que el de originación, pero en un monolito se escala todo junto
Ciclos de release lentos: un cambio pequeño requiere desplegar toda la aplicación, con sus riesgos asociados
Acoplamiento excesivo: un cambio en el módulo de pagos rompe el módulo de reportes porque comparten modelos de datos
Requisitos de disponibilidad diferenciada: el portal del cliente debe estar siempre disponible, pero el procesamiento batch de causación puede tolerar ventanas de mantenimiento

El patrón Strangler Fig

El Strangler Fig (higuera estranguladora) es un patrón de migración incremental inspirado en cómo una higuera crece alrededor de un árbol existente hasta reemplazarlo. Aplicado a software:

Identificar un dominio del monolito para extraer (por ejemplo, el módulo de notificaciones)
Construir el nuevo microservicio que implementa la funcionalidad del dominio seleccionado
Redirigir el tráfico: configurar un proxy o API gateway que envíe las peticiones del dominio migrado al nuevo servicio y el resto al monolito
Verificar: comparar resultados entre el monolito y el nuevo servicio para confirmar paridad funcional
Eliminar el código viejo: una vez que el nuevo servicio está estable, eliminar el código correspondiente del monolito
Repetir: seleccionar el siguiente dominio y repetir el proceso

Ventajas del Strangler Fig

Cero downtime: la migración es invisible para los usuarios
Riesgo controlado: si el nuevo servicio falla, el tráfico se redirige de vuelta al monolito
Progresiva: se puede pausar la migración en cualquier momento sin dejar el sistema en un estado inconsistente
Validable: se puede comparar el comportamiento del monolito con el del nuevo servicio antes de cortar

Descomposición por dominios de crédito

Para una fintech de crédito, los dominios naturales para la descomposición en microservicios son:

1. Originación

Responsabilidad: solicitudes de crédito, evaluación de riesgo, pre-aprobación, KYC
Datos propios: applications, kyc_validations, scoring_results
Interfaces: consulta a centrales de riesgo, validación SARLAFT

2. Cartera (Portfolio)

Responsabilidad: gestión del ciclo de vida del crédito, amortización, estado de cuenta
Datos propios: credits, amortization_schedules, credit_status
Interfaces: recibe créditos aprobados de Originación, envía información a Contabilidad

3. Pagos (Payments)

Responsabilidad: registro de pagos, distribución entre componentes, conciliación bancaria
Datos propios: payments, payment_distributions, bank_reconciliation
Interfaces: recibe pagos del banco, actualiza saldos en Cartera

4. Contabilidad (Accounting)

Responsabilidad: causación de intereses, asientos contables, provisiones, reportes financieros
Datos propios: accounting_entries, provisions, daily_accruals
Interfaces: recibe eventos de Cartera y Pagos, genera asientos automáticos

5. Cobranza (Collections)

Responsabilidad: gestión de mora, campañas de cobranza, acuerdos de pago, gestión prejudicial
Datos propios: collection_actions, payment_agreements, legal_proceedings
Interfaces: recibe alertas de mora de Cartera, registra acuerdos que afectan Cartera

6. Notificaciones

Responsabilidad: envío de emails, SMS y notificaciones push
Datos propios: notification_templates, notification_logs
Interfaces: recibe solicitudes de envío de todos los demás servicios

Checklist práctico para la migración

Antes de iniciar la migración, asegúrese de tener:

Contratos de API documentados: cada servicio define su API pública con schemas de request/response versionados
Propiedad de datos clara: cada servicio es dueño de sus datos y no accede directamente a la base de datos de otro servicio
Observabilidad: logging centralizado, tracing distribuido y métricas por servicio (herramientas como Grafana, Prometheus, Jaeger)
CI/CD por servicio: cada microservicio tiene su propio pipeline de build, test y deploy
Manejo de fallos: circuit breakers, retries con backoff exponencial y fallbacks para comunicación entre servicios
Estrategia de datos: plan para separar las tablas compartidas en schemas propios de cada servicio, posiblemente usando eventos para sincronización eventual

Errores comunes

Los errores más frecuentes en migraciones a microservicios incluyen:

Microservicios demasiado pequeños: crear un servicio por cada tabla o función genera una complejidad operativa insostenible
Base de datos compartida: si los servicios comparten la base de datos, no son verdaderos microservicios y el acoplamiento persiste
Ignorar la consistencia eventual: en un sistema distribuido, no siempre se puede tener consistencia inmediata; el equipo debe diseñar para consistencia eventual
Subestimar la complejidad operativa: monitorear, depurar y mantener 10 servicios es exponencialmente más complejo que mantener uno solo

Conclusión

La migración de monolito a microservicios en una fintech de crédito es una decisión que debe tomarse con base en problemas reales, no en tendencias tecnológicas. El patrón Strangler Fig permite ejecutar la migración de forma incremental y controlada, minimizando riesgos. La descomposición natural del dominio de crédito en originación, cartera, pagos, contabilidad y cobranza proporciona los límites claros que los microservicios necesitan para funcionar correctamente. La clave del éxito está en migrar con propósito, validar cada paso y no subestimar la complejidad operativa que los sistemas distribuidos introducen.