Arquitectura de microservicios: cuándo tiene sentido y cuándo es sobreingeniería

La arquitectura de microservicios se ha convertido en la respuesta automática a cualquier reto técnico. Startup con tres desarrolladores y cuatro usuarios beta: “vamos a hacerlo con microservicios”. Empresa tradicional digitalizando su backoffice: “necesitamos microservicios”. MVP que todavía no ha validado la idea: “mejor lo hacemos bien desde el principio, con microservicios”. El problema es que en la mayoría de esos casos la decisión es, directamente, un error de libro.

En Everglow llevamos años construyendo sistemas reales para empresas que facturan en serio, y hemos visto el patrón repetirse: equipos que adoptan microservicios porque “es lo moderno” y acaban con un sistema distribuido que nadie entiende, que tarda seis meses en desplegar una feature trivial y cuyo coste de infraestructura triplica lo previsto. Este artículo es la guía que te hubiera gustado tener antes de tomar esa decisión.

Qué es realmente una arquitectura de microservicios

Antes de decidir si los necesitas, conviene entender qué son. Una arquitectura de microservicios descompone una aplicación en servicios pequeños, independientes y desplegables por separado, cada uno con su propio ciclo de vida, su propia base de datos y, a menudo, su propio equipo. Los servicios se comunican entre sí mediante APIs, colas de mensajes o eventos.

Eso significa tres cosas que mucha gente pasa por alto:

• Cada servicio es una aplicación completa con su logging, observabilidad, despliegue, pipeline y documentación.
• La red deja de ser invisible. Todo lo que antes era una llamada a función ahora es una petición HTTP que puede fallar, degradarse o tardar.
• El estado global deja de existir. No tienes transacciones ACID cruzando servicios. Tienes que diseñar consistencia eventual y aceptar sus consecuencias.

Si cualquiera de esos tres puntos te suena a problema serio, probablemente no estás preparado para microservicios. Y no pasa nada: la mayoría de empresas no lo están.

Cuándo los microservicios sí tienen sentido

Hay escenarios donde una arquitectura de microservicios es la decisión correcta. Son menos de los que la industria sugiere, pero existen. Los hemos visto funcionar bien en estos contextos:

• Equipos de ingeniería grandes y autónomos. Si tienes más de 30–40 ingenieros distribuidos en múltiples squads y el monolito se ha convertido en un cuello de botella organizativo donde nadie puede desplegar sin bloquear a los demás, los microservicios aportan autonomía real.
• Componentes con requisitos de escalado radicalmente distintos. Una parte del sistema procesa vídeo, otra sirve una API pública con carga baja, otra hace analítica en batch. Empaquetarlo en un solo binario obliga a escalar el conjunto al peor caso.
• Módulos con ciclos de vida muy diferentes. Un motor de riesgos que actualizas a diario junto con un módulo de facturación que apenas cambia. Separarlos evita que los despliegues frecuentes arrastren al resto.
• Necesidades de aislamiento tecnológico. Una pieza crítica que tiene que estar en Rust por rendimiento, el resto del sistema en Node o Python. El aislamiento permite elegir la herramienta correcta para cada problema.
• Tolerancia a fallos diferenciada. Si la caída de un módulo no crítico no debe tirar el sistema completo, aislarlo tiene sentido.

Los microservicios son una solución a un problema organizativo disfrazada de solución técnica. Si tu organización no tiene ese problema, estás comprando el coste sin ningún beneficio real.

La pregunta que deberías hacerte no es “¿son buenos los microservicios?”, sino “¿qué problema concreto de mi negocio resuelvo con ellos y a qué coste?”. Si no puedes contestar a ambas preguntas con datos, todavía no es tu momento.

Cuándo los microservicios son sobreingeniería pura

En la mayoría de empresas medianas españolas, adoptar microservicios de entrada es un error caro. Estos son los síntomas que solemos encontrar cuando nos llaman para rescatar un proyecto:

1. El equipo tiene menos de 15 personas. No necesitas autonomía entre squads porque todavía no tienes squads. Tienes un único equipo que ahora debe coordinar despliegues entre cinco servicios en vez de uno.
2. No existe cultura de observabilidad. Si el equipo no sabe qué es trazabilidad distribuida, OpenTelemetry o un SLO, cada incidente se convertirá en una caza del tesoro de horas.
3. El producto aún no ha encontrado product-market fit. Cada pivote de negocio implica reescribir contratos entre servicios, migrar datos distribuidos y coordinar cambios en paralelo. Matas la velocidad justo cuando más la necesitas.
4. La base de datos se ha partido antes de entender el dominio. Separar datos sin un modelo de dominio claro es el camino directo a la inconsistencia crónica y a consultas cruzadas que reensamblan por código lo que antes hacía un JOIN.
5. No hay DevOps maduros. Microservicios sin automatización de despliegue, sin CI/CD sólido, sin infraestructura como código y sin gestión de secretos adecuada es garantía de caos operativo.

En todos esos casos, lo responsable es empezar por un monolito bien estructurado. Y esto no es una opinión contracultural: es lo que defiende Sam Newman —autor del libro de referencia del sector— y lo que recomienda explícitamente la literatura técnica de los últimos cinco años tras la resaca del hype.

El coste real que nadie te cuenta

Cuando una empresa nos pide una valoración sobre un sistema basado en microservicios, le pedimos que calcule honestamente estos costes. Casi nunca los habían cuantificado:

• Coste de infraestructura. Cada servicio necesita su runtime, su pod, su base de datos (o al menos su schema), su load balancer, su gateway. La factura de cloud puede ser entre 3 y 8 veces superior a la de un monolito equivalente.
• Coste de observabilidad. Necesitas logging centralizado, métricas, trazas distribuidas y alerting. No son opcionales: sin esto, depurar un error que cruza cinco servicios es imposible.
• Coste de operación. Desplegar no es ya “apretar un botón”. Es orquestar versiones compatibles entre servicios, contratos de API, migraciones coordinadas y rollbacks parciales.
• Coste cognitivo. Cada persona nueva en el equipo tarda entre dos y tres veces más en entender el sistema. La curva de onboarding se dispara.
• Coste de testing. El testing de integración deja de ser trivial. Necesitas contract testing, entornos replicados, fixtures coordinadas y una disciplina que la mayoría de equipos no tienen.

Si sumas todo eso honestamente, el ROI debe justificarlo. Y en la mayoría de empresas medianas, no lo justifica.

El monolito modular: la alternativa que casi siempre gana

La alternativa que recomendamos en Everglow para la mayoría de proyectos nuevos es el monolito modular. Es una aplicación única, desplegable como un solo binario o contenedor, pero internamente dividida en módulos con fronteras claras, dependencias explícitas y bases de datos lógicamente separadas (aunque físicamente compartan servidor).

Las ventajas son contundentes:

• Un único despliegue, un único pipeline, una única infraestructura que monitorizar.
• Transacciones ACID donde las necesitas, sin saga patterns ni consistencia eventual artificial.
• Refactorización masiva sin coordinar cambios entre servicios.
• Tiempo de onboarding de semanas en vez de meses.
• Si en tres años realmente necesitas extraer un módulo en un servicio independiente, las fronteras ya están definidas y la extracción es quirúrgica, no un rediseño.

La regla práctica que seguimos: empieza por un monolito modular bien diseñado. Extrae un servicio solo cuando tengas evidencia objetiva —no opinión, no hype— de que ese módulo necesita escalar, desplegarse o evolucionar de forma independiente.

Según un estudio de Gartner de finales de 2025, alrededor del 53% de las empresas que migraron de monolito a microservicios en los cinco años anteriores consideran que la migración no aportó el valor esperado o directamente lo destruyó. El caso paradigmático fue Amazon Prime Video, que en 2023 publicó un postmortem explicando cómo volver a un monolito les redujo el coste de infraestructura en un 90%.

Cómo decidir con criterio

Si después de leer esto sigues pensando que necesitas microservicios, haz este ejercicio antes de escribir una sola línea de código:

• Identifica qué módulos concretos necesitan escalado, equipo o despliegue independiente. Nómbralos.
• Calcula el coste adicional de infraestructura y operación durante los próximos 24 meses.
• Asegúrate de tener, o poder contratar, el talento DevOps y de plataforma necesario antes de empezar.
• Define contratos de API explícitos y versionados desde el día uno.
• Acuerda cómo gestionarás consistencia eventual, idempotencia y reintentos en cada interacción cross-service.
• Ten un plan claro de observabilidad antes del primer despliegue, no después del primer incidente.

Si no puedes contestar con rigor a cualquiera de estos puntos, aún no estás listo. Y empezar sin estar listo sale mucho más caro que esperar seis meses más.

Conclusión: el problema no son los microservicios, es elegirlos por inercia

Una arquitectura de microservicios bien ejecutada en el contexto correcto es potente. Pero adoptada por inercia, por moda o por miedo a “no estar haciendo lo moderno” es una de las decisiones más caras que puede tomar un equipo técnico. Y el coste no lo paga el equipo: lo paga el negocio, con proyectos que no llegan, presupuestos que se doblan y ventanas de oportunidad que se cierran.

En Everglow diseñamos arquitecturas pensando en tu negocio y tu equipo real, no en lo que queda bien en un blog técnico. Eso significa defender el monolito modular cuando toca, extraer servicios cuando hay evidencia objetiva, y acompañarte en la decisión con datos —no con dogma. Si estás a punto de decidir la arquitectura de un proyecto serio y quieres una segunda opinión sin humo, escríbenos a través de contacto y hablamos.