Caso
Migración de un monolito a microservicios
Extracción gradual de microservicios de un monolito sin tiempo de inactividad: límites de dominio, eventos y orquestación en Kubernetes.
- Año
- 2026
- Cliente
- Producto SaaS maduro
- Rol
- Tech Lead
Descripción
Un monolito maduro en Laravel dejó de cumplir los requisitos del negocio: los despliegues se volvieron arriesgados, los equipos se estorbaban entre sí y algunos módulos de alta carga no podían escalarse de forma independiente. Lideré una migración por fases a microservicios con la estrategia strangler fig (higuera estranguladora), sin detener el producto. Empezamos trazando los límites por dominios basándonos en DDD, luego extrajimos los servicios de forma secuencial, pasando la interacción entre módulos a eventos asíncronos a través de un broker de mensajes y un transactional outbox para una publicación fiable. Los servicios más críticos en latencia están implementados en Go, mientras que los de producto permanecieron en Laravel. Todos los servicios están contenedorizados y desplegados en Kubernetes con pipelines de CI/CD independientes, autoescalado y observabilidad completa: registros estructurados con identificadores de correlación, métricas de Prometheus y trazado distribuido. El monolito, mientras tanto, seguía funcionando, adelgazando poco a poco a medida que se extraía la funcionalidad.
Problema
El monolito se convirtió en un cuello de botella: cualquier despliegue afectaba a todo el sistema y conllevaba riesgo, los equipos entraban en conflicto en el código y la base de datos compartidos, y los módulos de alta carga no podían escalarse por separado del resto.
Solución
Apliqué la estrategia strangler fig: definí los límites de dominio, extraje los servicios por fases con intercambio asíncrono de eventos y un outbox, reescribí las partes de alta carga en Go y desplegué todo en Kubernetes con pipelines separados y observabilidad de extremo a extremo.
Resultados
La frecuencia de despliegues aumentó 4 veces, el tiempo de recuperación tras incidentes se redujo a un tercio, los servicios de alta carga escalan de forma independiente, la migración se realizó sin tiempo de inactividad del producto y el tiempo para lanzar nuevas funciones se redujo en un 40%.