De monolito a microservicios: como migrar sin romper todo

La industria tiene un amor incondicional por los microservicios desde el dia cero. Pero para la mayoria de los proyectos, arrancar con un monolito es la decision mas racional: menos infraestructura, menos complejidad operativa, iteraciones mas rapidas. No tiene sentido resolver problemas de escala que todavia no existen.

Mi approach personal: arranco monolitico, shipeo rapido, mido el trafico real, y solo pienso en dividir cuando hay evidencia concreta de un cuello de botella. La sobreingenieria prematura en arquitectura es tan danina como en codigo.

Aunque corra en un solo proceso, el codigo esta dividido por dominio: cada modulo tiene su propio router, controller y service. Auth maneja todo lo relacionado a autenticacion, Products tiene sus rutas, su logica de negocio y su acceso a la DB. El monolito es un proceso unico, pero la arquitectura interna es modular.

Esta separacion no es solo estetica. Es la que hace posible la extraccion futura. Cuando el modulo Orders tiene limites claros y no esta acoplado con el resto, puede moverse a su propio servicio sin reescribir desde cero.

Antes de cualquier decision de arquitectura necesito datos. Mi approach: un middleware simple que intercepta cada request y loguea lo minimo necesario en una tabla de la misma base de datos del monolito. Nada de Datadog, nada de Prometheus. Solo SQL y lo que ya tengo.

La tabla tiene campos basicos: modulo, endpoint, metodo HTTP, tiempo de respuesta en milisegundos y status code. Con eso puedo responder las preguntas que importan: cual modulo concentra mas carga, cual tiene los tiempos mas altos, cual esta creciendo.

Es deliberadamente rustico porque en la etapa inicial no quiero dependencias externas ni infra extra. La herramienta de monitoreo mas util es la que ya tengo desplegada.

Con algunas semanas de datos, el patron aparece. Alguno de los modulos concentra el 60% de los requests, o tiene tiempos promedio tres veces mas altos que el resto. Eso es el primer candidato.

Pero la decision de extraer no es solo por volumen. Lo que importa es si la carga de ese modulo esta degradando la experiencia del resto. Si el modulo Reports es lento pero no interfiere con el checkout, quizas alcanza con optimizar internamente. Si esta bloqueando el event loop y ralentizando el login, ahi si hay un problema real.

Una vez identificado el candidato, arranca la extraccion. Como el modulo ya tiene limites claros dentro del monolito, la mayor parte del trabajo es mover codigo, no reescribirlo. Creo un nuevo servicio con su propio repo, su propia base de datos y su propio proceso de deploy.

La estrategia de datos es lo mas delicado. El modulo extraido necesita su propia DB, pero la data historica esta en la DB del monolito. Dependiendo del caso puede ser una migracion completa, un periodo de escritura doble, o simplemente que el servicio nuevo arranca limpio y el monolito sigue siendo el source of truth para datos viejos.

Mientras el microservicio se estabiliza, el monolito puede actuar como proxy: recibe los requests del modulo extraido y los redirige al nuevo servicio. Esto permite rollback rapido si algo sale mal.

El microservicio extraido necesita comunicarse con el monolito. Mi eleccion por defecto es Redis, especificamente pub/sub para eventos asincronicos y BullMQ para tareas que necesitan persistencia y retry. Por que Redis? Porque ya lo uso para cache en casi todos los proyectos, es rapido, y maneja bien tanto eventos fire-and-forget como comunicacion mas estructurada.

El patron basico: cuando sucede algo relevante en el monolito (por ejemplo, se creo un pedido), publica un evento en Redis. El microservicio correspondiente esta suscripto a ese canal y lo procesa de forma independiente. Si el microservicio esta caido, los mensajes se acumulan en la queue y los procesa cuando vuelve.

HTTP directo entre servicios lo reservo para casos donde necesito una respuesta sincrona inmediata. Para todo lo demas, el bus de Redis da desacoplamiento y amortigua naturalmente los picos de carga.

Un caso concreto donde BullMQ brilla son los procesos async pesados: generacion de contenido con IA, video, imagenes, deep research. En vez de que la app principal los ejecute y bloquee sus propios hilos, los encola en Redis y workers dedicados los procesan de forma independiente.

La extraccion no es un evento de big bang donde un dia paso de monolito a microservicios. Es un ciclo: monitoreo, detecto el modulo con mas impacto, lo extraigo, lo estabilizo, y vuelvo a monitorear. Cada vuelta del ciclo deja al monolito un poco mas liviano.

El monolito rara vez desaparece del todo, y esta bien. Los modulos que tienen poco trafico y no generan cuellos de botella no justifican la complejidad operativa de ser servicios independientes. Con el tiempo el monolito se convierte en el core que maneja los dominios menos exigentes, rodeado de microservicios especializados en lo que mas carga genera.

Despues de varios ciclos de extraccion, el resultado es un monolito mas pequeno manejando los dominios base, mas algunos microservicios especializados comunicados a traves de Redis. Cada servicio tiene su propia base de datos, su propio pipeline de deploy y puede escalar de forma independiente.

Esto no es la arquitectura de Netflix con 500 servicios. Es algo pragmatico: 3 a 5 servicios extraidos basados en evidencia real, con el resto de la logica viviendo en un monolito que ahora es mas rapido porque tiene menos responsabilidades.

Ninguno de los tres enfoques es universalmente correcto. La tabla muestra los tradeoffs reales dependiendo de donde este parado el proyecto y el equipo.

Este approach no es para todos los proyectos. Si el monolito anda bien y los tiempos de respuesta son aceptables, no toques nada. Agregar la complejidad operativa de microservicios a un sistema que no tiene problemas de escala es sobreingenieria pura.

Tampoco tiene sentido extraer sin datos. Todo el approach se basa en medir primero y decidir despues. Sin monitoreo, cualquier decision de arquitectura es una adivinanza. Y las adivinanzas en arquitectura son caras.