¿Monolito modular o microservicios? Que decida el producto.

Una decisión de arquitectura que puede encarecer cada entrega

Los microservicios pueden ser la opción adecuada. Un monolito modular también. El error costoso es elegir uno por moda y hacer que el producto y el equipo paguen después por esa incompatibilidad.

Un monolito modular mantiene límites internos claros con operaciones y despliegues relativamente sencillos. Los microservicios añaden unidades que se despliegan de forma independiente, junto con la red, la observabilidad, la coordinación de datos y la responsabilidad operativa que esto implica.

La pregunta no es «¿qué arquitectura es más moderna?». Es «¿qué restricciones tiene realmente nuestro producto?».

Decide con evidencias, no con mitos de arquitectura

Antes de separar servicios, evalúa seis señales:

• Límites de dominio: ¿pueden los equipos describir capacidades de negocio estables y sus contratos?
• Ritmo de entrega: ¿hay partes del producto que necesitan publicarse de forma independiente?
• Escalabilidad: ¿una capacidad soporta una carga muy distinta a la del resto?
• Responsabilidad del equipo: ¿hay un equipo capaz de hacerse cargo de cada servicio de principio a fin?
• Consistencia de datos: ¿el flujo tolera coordinación asíncrona y consistencia eventual?
• Preparación operativa: ¿la organización puede observar, proteger, desplegar y recuperar muchos servicios?

Si los límites aún cambian, los flujos están muy acoplados y un equipo pequeño es responsable del producto, un monolito modular puede mantener la velocidad y hacer explícito el dominio. Si capacidades bien definidas necesitan despliegues o escalado independientes —y los equipos pueden asumir las consecuencias operativas—, los servicios pueden justificar su coste.

Conserva la opción de cambiar

Empieza haciendo cumplir los límites entre módulos dentro del monolito: interfaces explícitas, dependencias controladas y responsabilidades claras. Mide dónde los cambios cruzan límites repetidamente, dónde un despliegue bloquea a otro y dónde las necesidades de escalabilidad o fiabilidad divergen de verdad.

Extrae un servicio solo cuando las evidencias señalen un límite concreto. Define su contrato, la propiedad de los datos, el comportamiento ante fallos y el plan de reversión antes de mover código. La separación debe eliminar una restricción que el equipo pueda nombrar, no crear un diagrama vistoso.

Trata la arquitectura como una decisión de producto

Conecta la arquitectura con los objetivos del producto, las decisiones y las evidencias. Registra por qué existe un límite, qué podría invalidar la decisión y cómo detectará el equipo una desviación. Una comprobación ligera de arquitectura puede señalar dependencias prohibidas antes de que se extiendan.

ArchGenerator.com ayuda a que estas decisiones sean visibles y gobernables: desde el descubrimiento y la arquitectura hasta las especificaciones, la guía de implementación y la evolución continua. Mantén una arquitectura proporcionada al producto actual, con un camino claro hacia el producto que estás construyendo.

Lista de decisión: ¿cuál es la restricción? ¿Qué evidencia demuestra que existe? ¿Quién es responsable del límite? ¿Qué capacidad operativa exige esta opción? ¿Qué señal indicaría que toca revisarla?