La pregunta que casi siempre llega mal planteada
Con cierta frecuencia un cliente nos pide microservicios antes de que le preguntemos qué problema está tratando de resolver. Microservicios se volvió sinónimo de «arquitectura moderna», y monolito de «código viejo». En la práctica, la elección no tiene nada que ver con qué tan moderno se vea el proyecto, sino con el tamaño del equipo, qué tan rápido cambia el negocio, y qué tan bien conoces todavía el dominio que estás construyendo.
Lo que cuesta un microservicio desde el día uno
Separar un sistema en servicios independientes trae, además de sus beneficios reales, una factura inmediata: más piezas de infraestructura que mantener, comunicación entre servicios que puede fallar en red (algo que no existía cuando todo vivía en un mismo proceso), y un equipo que necesita disciplina de versionado de APIs internas desde el primer día. Para un equipo de tres o cuatro desarrolladores, esa factura casi nunca vale la pena todavía.
Qué es un monolito híbrido
Le llamamos monolito híbrido a un solo código base, con un solo despliegue, pero organizado internamente en módulos con fronteras claras —cada uno responsable de un dominio del negocio (facturación, inventario, notificaciones), con sus propias interfaces internas bien definidas. La regla es simple: los módulos se comunican a través de interfaces explícitas, nunca compartiendo tablas o variables internas directamente. Eso da la mayoría de las ventajas de organización que promete la arquitectura de microservicios, sin pagar el costo operativo de tener diez servicios corriendo por separado.
Por qué esto facilita crecer después
Si un módulo realmente necesita escalar aparte —por ejemplo, un proceso pesado de generación de reportes que satura el resto del sistema—, separarlo en su propio servicio después es mucho más fácil cuando ya tenía una frontera clara desde el diseño. Extraer un módulo bien delimitado de un monolito híbrido toma días; deshacer el enredo de un monolito sin fronteras internas puede tomar meses.
Cuándo sí conviene empezar con microservicios
Cuando el equipo ya es grande y necesita que varios grupos trabajen sin pisarse el código entre sí, cuando ya se conoce bien el dominio y las fronteras entre módulos son estables, o cuando una parte específica del sistema tiene requisitos de escalamiento muy distintos al resto —ahí sí, separar desde el inicio se paga solo. Fuera de esos casos, casi siempre recomendamos empezar simple y dejar la puerta abierta para separar después.
Revisamos tu arquitectura actual y te decimos, sin venderte nada de más, qué tanto sentido tiene separar servicios en tu caso.