Arquitectura de microservicios: cuándo tiene sentido y cuándo es un error

Pocas decisiones de arquitectura generan tanto ruido de fondo como “¿monolito o microservicios?”. Durante buena parte de la década de 2010 la respuesta correcta parecía obvia en cualquier charla de conferencia: microservicios, casi sin excepción. Los datos de adopción de estos últimos años cuentan una historia distinta. Según la encuesta State of Cloud Native de la CNCF, alrededor de un 42% de las organizaciones que habían adoptado microservicios estaban en 2025 consolidando parte de esos servicios de vuelta en unidades más grandes, citando como motivos principales la complejidad de depuración, la sobrecarga operativa y la latencia de red.

Eso no convierte a los microservicios en un error generalizado. Convierte en un error la costumbre de adoptarlos sin haber hecho antes la pregunta que de verdad importa: ¿qué problema concreto resuelve esta arquitectura en mi caso, y estoy dispuesto a pagar su factura?

Qué problema resuelven realmente los microservicios

Los microservicios no existen para que el código “esté más ordenado”. Existen para desacoplar tres cosas que en un monolito viven forzosamente juntas: el ciclo de despliegue, el ciclo de escalado y la propiedad organizativa del código.

• Escalado independiente. Si un componente de tu sistema consume diez veces más CPU o memoria que el resto —procesamiento de imágenes, generación de PDFs, un motor de recomendaciones—, separarlo permite darle recursos propios sin replicar toda la aplicación solo para esa pieza.
• Autonomía de equipo. Cuando dos equipos trabajan sobre la misma base de código, cada despliegue de uno puede bloquear o pisar al otro. Una frontera de servicio bien trazada elimina esa coordinación manual: cada equipo despliega cuando quiere, con su propio ciclo de vida.
• Aislamiento por fiabilidad o cumplimiento normativo. Un componente que maneja datos de tarjetas de pago o información sanitaria puede necesitar vivir en un perímetro de seguridad y auditoría distinto, con sus propias credenciales y su propio radio de explosión si falla.

Estos tres beneficios son reales y, en el sistema y la organización adecuados, valen mucho más que lo que cuestan. El problema no es el patrón: es aplicarlo cuando ninguna de esas tres necesidades existe todavía, solo porque “así es como se construyen los sistemas serios”.

La factura operativa que casi nadie enseña en la charla de conferencia

Cuando una función deja de ser una llamada dentro del mismo proceso y pasa a ser una petición de red entre dos servicios, no cambia solo la implementación: cambia la naturaleza de lo que puede salir mal.

graph TD
subgraph Monolito modular
  M1[Módulo Pedidos] -->|llamada de función| M2[Módulo Inventario]
  M2 -->|misma transacción ACID| M3[(Una base de datos)]
end
subgraph Microservicios
  S1[Servicio Pedidos] -->|petición de red| S2[Servicio Inventario]
  S2 -->|consistencia eventual| S3[(BD Inventario)]
  S1 --> S4[(BD Pedidos)]
  S1 -.->|timeout / reintento / circuit breaker| S2
end

En el monolito, si el módulo de inventario no tiene stock, la transacción falla dentro del mismo proceso y se revierte de forma atómica. En microservicios, esa misma operación implica una llamada de red que puede tardar, fallar a medias o llegar duplicada, y que exige diseñar explícitamente qué pasa si el servicio de pedidos confirma pero el de inventario no responde a tiempo.

Complejidad operativa

Cada servicio nuevo es, como mínimo, un pipeline de CI/CD adicional, un conjunto de credenciales que rotar, un panel de métricas que vigilar y un proceso más que puede fallar a las tres de la madrugada. Un análisis reciente sobre el coste operativo real de los microservicios estima que un monolito modular puede sostenerse con uno o dos ingenieros centrados en operaciones, mientras que una arquitectura de microservicios equivalente suele necesitar entre dos y cuatro ingenieros de plataforma dedicados, además de la carga operativa que cada equipo de producto asume por sus propios servicios. Eso no es una anécdota: es una plantilla que hay que presupuestar antes de decidir, no después de sufrirla.

Latencia de red y fallos parciales

Una llamada de función nunca fue lenta ni falló a medias. Una llamada de red sí puede hacer ambas cosas: puede tardar 5 milisegundos o 5 segundos, puede caerse justo cuando el otro servicio está desplegando una nueva versión, puede devolver una respuesta parcial. Un sistema con diez microservicios en cadena para atender una sola petición de usuario acumula diez oportunidades de fallo parcial donde el monolito tenía cero. Gestionar eso bien no es opcional: exige aplicar de forma sistemática patrones de resiliencia como circuit breakers, reintentos y timeouts, no como parche cuando algo ya se ha caído en producción.

Consistencia distribuida

En una base de datos única, una transacción que toca “pedido” y “stock” a la vez es atómica: o se aplican los dos cambios, o no se aplica ninguno. En cuanto pedidos y stock viven en bases de datos distintas, detrás de servicios distintos, esa garantía desaparece. La alternativa habitual es el patrón saga: una secuencia de pasos locales, cada uno con su propia transacción de compensación por si un paso posterior falla y hay que deshacer lo ya hecho. Diseñar sagas correctamente —sobre todo las compensaciones— es trabajo de ingeniería real, con casos límite incómodos (¿qué pasa si la compensación también falla?) que en un monolito ni siquiera existían como pregunta.

El dato que confirma la corrección de rumbo

El caso de sobrecorrección más citado del sector es Amazon Prime Video, que en 2023 documentó públicamente cómo su equipo de monitorización de calidad de vídeo —el componente que analiza en tiempo real cada stream que ve un cliente— pasó de una arquitectura distribuida de microservicios y funciones serverless orquestadas con AWS Step Functions a un único servicio desplegado sobre ECS. El resultado fue una reducción de costes de infraestructura de alrededor del 90% para ese componente concreto, principalmente por eliminar las llamadas a S3 como almacenamiento intermedio entre pasos y la sobrecarga de orquestación entre servicios. Es un caso puntual, no una prueba de que “los microservicios estén acabados”, pero ilustra bien el patrón: un componente con una carga de trabajo intensa y muy acoplada internamente puede pagar más por estar distribuido de lo que gana en flexibilidad. Es la misma lógica que explica por qué la adopción de service mesh —la maquinaria de red que las arquitecturas de microservicios maduras suelen necesitar— cayó de forma notable en las encuestas de la CNCF de los últimos dos años, señal indirecta de que menos equipos quieren seguir manteniendo esa capa de complejidad.

Ninguno de estos datos dice “no uses microservicios”. Dicen que una parte significativa de las organizaciones que los adoptaron lo hicieron sin que el problema lo justificara, y que corregirlo tiene un coste, pero es mejor pagarlo tarde que nunca.

Señales reales de que sí conviene separar un servicio

La pregunta útil no es “¿somos ya lo bastante grandes para microservicios?” sino “¿puedo nombrar el servicio concreto que extraería y la razón concreta por la que lo haría?”. Las señales que justifican la extracción, sobre todo cuando aparecen dos o más a la vez, son:

1. Un componente necesita escalar de forma radicalmente distinta al resto. Si el 90% de tu tráfico es lectura ligera pero un 5% del sistema hace procesamiento pesado de CPU, forzar a todo el monolito a escalar junto es desperdiciar dinero.
2. Dos equipos se bloquean mutuamente en el mismo despliegue. Si coordinar una ventana de despliegue entre equipos es una reunión recurrente en tu calendario, la frontera organizativa ya existe de facto; formalizarla como frontera de servicio solo reconoce lo que ya es cierto.
3. Aislamiento por seguridad o cumplimiento normativo. PCI-DSS, HIPAA o normativas equivalentes a veces exigen perímetros de red y auditoría separados que un monolito no puede ofrecer sin artificios.
4. Ciclos de vida de despliegue genuinamente distintos. Un modelo de machine learning que se reentrena y despliega varias veces al día no debería forzar un redespliegue completo del resto del sistema cada vez que cambia.

Señales de que es un error (y por qué se comete tanto)

• “Lo hacen las empresas grandes.” Netflix, Amazon o Uber operan a una escala de miles de ingenieros y cientos de millones de usuarios. Copiar su arquitectura sin tener ni remotamente su escala ni su equipo de plataforma es importar el coste sin importar el contexto que lo justifica.
• Fronteras de servicio decididas antes de conocer bien el dominio. Al principio de un proyecto, la incertidumbre sobre dónde están los límites naturales del negocio es máxima. Trazar fronteras de red —mucho más caras de corregir que fronteras de módulo— sobre un dominio que todavía no entiendes bien casi garantiza tener que rehacerlas.
• Un solo equipo, muchos servicios. Si un equipo de cinco personas mantiene veinte microservicios, no ha ganado autonomía: ha multiplicado por veinte la superficie que tiene que vigilar, desplegar y depurar, sin que exista ningún segundo equipo que se beneficie de esa separación.
• Ausencia de plataforma de soporte. Operar microservicios en condiciones exige observabilidad distribuida (trazas correlacionadas entre servicios), gestión de contenedores y un pipeline de despliegue maduro. Adoptar el patrón antes de tener esa base es construir sobre arena.

Recomendación práctica

Si estás decidiendo la arquitectura de un sistema nuevo, o evaluando si conviene trocear uno existente, el orden que minimiza arrepentimientos es:

1. Empieza con un monolito modular con fronteras internas explícitas: mismo proceso de despliegue, pero módulos que se comunican solo a través de una API interna bien definida, nunca accediendo a las tripas de otro módulo.
2. Instrumenta el sistema para saber, con datos reales y no intuición, qué componente consume más recursos, cuál cambia con más frecuencia y dónde se bloquean los equipos entre sí.
3. Extrae un único servicio cuando puedas nombrar la señal concreta que lo justifica —preferiblemente empezando por los componentes con menos dependencias del resto del dominio, para validar tu tubería de despliegue distribuido antes de tocar el núcleo transaccional del sistema.
4. Antes de extraer un segundo o tercer servicio, asegúrate de tener resuelto lo básico de observabilidad distribuida y los patrones de resiliencia que la comunicación entre servicios exige de forma no negociable.

Los microservicios no son ni el futuro inevitable de cualquier sistema que crezca ni una moda superada. Son una herramienta con un coste operativo alto y un beneficio muy concreto, que solo compensa cuando el problema que tienes delante —de escala, de organización o de cumplimiento normativo— es real y no anticipado. La arquitectura correcta es la que tu equipo, con su tamaño y su madurez operativa actuales, puede sostener sin que nadie tenga que rehacerla desde cero dentro de un año.