La pregunta correcta no es técnica, es organizativa
Los microservicios rara vez fracasan por razones técnicas: fracasan porque se adoptan para resolver un problema que no se tenía. Antes de dividir un sistema, la pregunta no es "¿puedo?", sino "¿qué problema concreto de escala, despliegue o equipos me obliga a hacerlo?". Si no hay una respuesta clara, probablemente la respuesta es no.
Qué resuelven los microservicios
Resuelven bien tres cosas: escalar partes del sistema de forma independiente, permitir que varios equipos desplieguen sin pisarse, y aislar dominios que evolucionan a ritmos distintos. Si tu cuello de botella es uno de esos tres, los microservicios son una herramienta legítima.
Qué cuestan
A cambio, introducen complejidad operativa real: red entre servicios, consistencia eventual, observabilidad distribuida, versionado de contratos, despliegues coordinados y depuración más difícil. Un equipo pequeño puede pasar más tiempo administrando la infraestructura que resolviendo el negocio.
El monolito modular: la opción por defecto
Para la mayoría de los proyectos, un monolito bien modularizado —con fronteras internas claras entre dominios— ofrece casi todos los beneficios de diseño sin el costo operativo. Y deja abierta la puerta: un módulo bien aislado se puede extraer a un servicio el día que de verdad haga falta.
Una regla práctica
Empieza con un monolito modular. Extrae un servicio solo cuando tengas una razón concreta y medible: este componente necesita escalar aparte, este equipo necesita desplegar aparte, este dominio cambia con otra cadencia. La arquitectura debe seguir al problema, no anticiparse a uno que quizá nunca llegue.