Migración del Programa de Lealtad a Microservicios
Cómo transformamos un sistema monolítico con 70,000+ usuarios activos en una arquitectura de microservicios —sin un minuto de downtime— y con resultados de negocio medibles.
El Reto
El programa de lealtad de Revenatium había crecido dentro de un monolito Java. Con más de 70,000 usuarios activos, el sistema enfrentaba problemas críticos que bloqueaban el crecimiento:
- → Acoplamiento total: Cualquier cambio en el módulo de lealtad requería redeploy completo de la plataforma, afectando al motor de reservaciones y al resto de servicios.
- → Escalabilidad limitada: En temporadas altas (puentes y festividades), no era posible escalar el módulo de lealtad de forma independiente sin afectar el costo de toda la plataforma.
- → Deuda técnica acumulada: El código llevaba años sin refactorización significativa. Añadir funcionalidades tomaba semanas en lugar de días.
- → Riesgo de negocio alto: Un bug en el módulo de lealtad podía comprometer reservaciones activas. El costo de un fallo era enorme.
El reto no era solo técnico: había que migrar con el sistema en producción, sin afectar a los 70,000 usuarios activos y sin que el equipo de negocio percibiera ninguna interrupción.
La Arquitectura y Decisiones Técnicas
Elegimos una estrategia de migración gradual basada en el patrón Strangler Fig: no reescribimos el sistema desde cero, sino que fuimos extrayendo módulos del monolito hacia microservicios autónomos de forma progresiva, usando el API Gateway como punto de control del tráfico.
Arquitectura Inicial — Monolito
Arquitectura Nueva — Microservicios
¿Por qué Spring Boot?
El equipo ya tenía expertise en Java. Spring Boot nos dio un path de migración incremental sin tener que reescribir en un lenguaje nuevo. La madurez del ecosistema —Spring Cloud, Actuator, Micrometer— fue clave para tener observabilidad desde el día uno.
¿Por qué AWS ECS y no Kubernetes?
La decisión de no ir a K8s fue deliberada. El equipo era pequeño y la complejidad operacional de Kubernetes hubiera sido over-engineering para nuestro tamaño en ese momento. ECS nos dio orquestación de contenedores con una curva de aprendizaje manejable.
El Impacto
Al poder desplegar mejoras del programa de forma independiente y frecuente, la tasa de adopción creció sostenidamente tras la migración.
La estrategia de routing progresivo garantizó continuidad total del servicio para los 70,000+ usuarios activos durante todo el proceso.
De deploys semanales que afectaban toda la plataforma, a deploys diarios por servicio con riesgo contenido y rollback automático.
Un bug en notificaciones ya no impacta al motor de reservaciones. La resiliencia del sistema mejoró radicalmente.
Lección clave
La migración de un monolito no es un proyecto de "big bang". El éxito vino de tener paciencia para dar pasos pequeños y reversibles, mantener el sistema en producción funcionando en todo momento, y definir métricas de éxito claras antes de declarar que algo estaba "migrado".
Stack Utilizado
¿Tienes un sistema que necesita evolucionar?
Hablemos sobre arquitectura y estrategias de migración.
Escribirme