I am Lino
9 de marzo de 2026

Microservicios, monolitos y otras criaturas mitológicas

Publicado el 9 de marzo de 2026  •  15 minutos  • 3033 palabras
Table of contents

Hay arquitecturas que se eligen con calma, con datos, con un café delante.

Y luego está la vida real, donde eliges tecnología como quien elige equipo de fútbol: porque la viste en una charla molona, porque la usa una empresa famosa o porque alguien tuiteó que “si no tienes 80 microservicios en Kubernetes eres un dinosaurio”.

De repente, pasas de tener un monolito entrañable, un poco caótico pero funcional, a un zoológico de servicios donde nadie sabe muy bien qué habla con qué, tu factura de cloud da miedo y el único microservicio que funciona impecable es el que cobra a fin de mes. Y todo porque, en algún punto, se dejó de hacer la única pregunta importante:

“¿Qué problema real estoy intentando resolver?”

Este artículo va precisamente de eso. De bajar el volumen del ruido, de mirar con calma al monolito (ese viejo amigo injustamente insultado), de reírnos un poco de los microservicios convertidos en religión y, sobre todo, de salir con un criterio que te sirva cuando alguien pregunte: “¿y esto lo hacemos en monolito o en tropecientos servicios?”.

Monolitos: el amigo feo que siempre está cuando lo necesitas

Empecemos por el sospechoso habitual. Un monolito es básicamente una aplicación empaquetada y desplegada como una sola pieza . No es glamuroso, no da para muchas conferencias, pero durante décadas ha servido para que millones de usuarios hagan cosas aburridas pero esenciales: pagar facturas, comprar cosas, reservar vuelos, esas pequeñeces.

La magia del monolito es que muchas cosas simplemente… tiran solas. Todo está en el mismo proceso, así que las llamadas internas son locales: nada de redes caprichosas, nada de latencias fantasmas, nada de "¿por qué tarda 400 ms en ir del servicio A al B si están en la misma VPC?". Lo arrancas en tu máquina y, en general, tienes casi todo el sistema delante, sin levantar tres clusters y cuatro túneles SSH para depurar un bug. Y el despliegue se parece más a: “subimos una versión nueva” que a “planificamos el Día del Juicio Final”.

Hasta aquí, todo bien. ¿Dónde se tuerce? En el mismo sitio donde se tuerce casi todo en ingeniería: cuando se hace crecer un sistema sin diseño , sin disciplina y sin nadie levantando la mano para decir “igual esto ya no deberíamos hacerlo así”.

Ahí es cuando el monolito se convierte en la famosa bola de barro : cualquier módulo puede llamar a cualquier otro, las capas se mezclan, las reglas de negocio viven en controladores y triggers de base de datos por igual, y un cambio en facturación rompe informes, notificaciones y la pantalla de login a la vez.

Y aquí viene la parte incómoda: eso no es culpa intrínseca del monolito. Eso es culpa del caos. Si coges esa misma actitud y la aplicas a microservicios, lo único que haces es repartir la bola de barro por la red , con más latencia y más facturas de AWS.

Por eso, muchos arquitectos modernos se han reconciliado con un concepto que suena casi provocador: el monolito modular. Por fuera sigues desplegando una sola aplicación, pero por dentro decides que no todo puede hablar con todo. Dominios como Pedidos, Usuarios, Catálogo, Pagos se convierten en módulos separados, con sus propias reglas, dependencias controladas y una puerta de entrada clara.

No es un invento nuevo, pero sí es de lo más moderno que hay: te quedas con las ventajas operativas del monolito (pocas piezas, latencia mínima, despliegue relativamente simple) y, al mismo tiempo, evitas la sensación de “cualquier cambio toca media galaxia”. Y, detalle importante: si un día necesitas sacar Pagos a un servicio aparte porque el negocio creció, ya tienes media operación hecha . Solo tienes que mover un módulo bien delimitado, no una maraña.

Para una startup, para un producto joven, para un equipo de 3-7 personas que todavía está descubriendo qué puñetas quiere el mercado, un buen monolito modular suele ser la opción más moderna que puedes elegir , aunque no venga con pegatina de microservicios.

Microservicios: el traje de superhéroe que viene sin instrucciones

En las presentaciones, los microservicios parecen el invento del siglo: muchos servicios pequeños, cada uno haciendo una cosa, alineados con dominios de negocio, desplegables de forma independiente, escalables a voluntad. Un sueño húmedo de autonomía y escalabilidad.

Y ojo: hay casos donde esto no es ciencia ficción, es la realidad. Empresas como Netflix, Amazon o Uber no se pasaron a microservicios por postureo, sino porque sus problemas eran de los que no arreglas con un par de índices y algo de caching.

Netflix necesitaba servir vídeo a millones de usuarios simultáneos, en todo el mundo, sin caerse cada vez que alguien estrenaba una serie gorda. Pasar de un monolito a una arquitectura de servicios les permitió escalar justo lo que hacía falta, aislar fallos y experimentar sin romperlo todo cada vez. Pero no lo hicieron a lo loco: acompañaron la jugada con prácticas como Chaos Monkey, que es, literalmente, un servicio que se dedica a romper cosas en producción para obligarte a diseñar pensando en el fallo.

Amazon hizo algo parecido alineando servicios con capacidades de negocio: inventaron algo llamado “two-pizza teams” (equipos lo bastante pequeños como para alimentarse con dos pizzas) y el mantra de “you build it, you run it”: si construyes un servicio, también lo operas (“el que la propone, se la come”). Eso solo tiene sentido si puedes desplegar partes del sistema sin arrastrar todo lo demás.

Uber, por su parte, se encontró con un monolito global donde cada cambio era un deporte de riesgo a escala planetaria. Trocear en servicios les permitió desplegar y escalar por zonas, ciudades, funcionalidades. De nuevo, dolor gigantesco primero, muchas historias de terror interno, pero con una presión que justificaba el salto.

El patrón común: presión real , escalado brutal, negocio 24/7, equipos enormes, requisitos de disponibilidad que te impiden apagar nada sin que alguien pierda dinero.

¿Y los fracasos? También abundan. Hay casos muy documentados, como el de HeartFlow en una migración de identidad , donde un salto apresurado a microservicios dejó a todos los usuarios bloqueados el día del lanzamiento, con un plan de rollback digno de película de terror. Tuvieron que volver al monolito, replantear la estrategia y, la siguiente vez, hacerlo con canaries, ejecuciones en paralelo y mucha menos arrogancia.

Otros estudios recogen historias menos espectaculares pero igual de dolorosas: empresas que, tras “migrar a microservicios”, acabaron con más caídas, más latencia y más complejidad operativa que antes. Múltiples servicios pequeños, sí; pero todos pegados a la misma base de datos gigante, sin trazas distribuidas, con versionados de APIs improvisados y guardias convertidas en ruleta rusa.

La moraleja duele, pero es lo que hay: los microservicios no arreglan una mala arquitectura, solo la distribuyen por la red.

Mitos que habría que jubilar (con honores… y distancia)

Hay unas frases que vuelven una y otra vez en cualquier debate de arquitectura y cuando se repiten las suficientes veces, se convierten en dogma.

Ahí van tres de mis favoritas.

“Microservicios = moderno, monolito = viejuno”

“En mi cabeza sonaba bien”, pero es falso.

Hay monolitos perfectamente modernos: desplegados en la nube, con CI/CD decente, observabilidad razonable, dominio bien dividido en módulos, tests de integración que no dan miedo y una experiencia de desarrollador que no hace llorar.

Y hay microservicios que son, simplemente, un monolito distribuido: cada equipo copia y pega patrones, nadie sabe quién es dueño de qué, se comparte una base de datos central “provisional” desde hace cinco años y cualquier cambio de esquema es un festival del humor.

La arquitectura moderna no va de número de servicios, va de propiedades: acoplamiento, cohesión, lo fácil que es meter mano, resiliencia, costes. Lo demás es ruido.

“Los microservicios siempre escalan mejor”

Escalan distinto, que no es lo mismo.

En teoría te permiten escalar solo lo que duele: si búsqueda sufre, subes instancias de ese servicio y listo. En la práctica, hay estudios de rendimiento que muestran que los sistemas distribuidos introducen overhead de red, nuevas fuentes de latencia y puntos de fallo que simplemente no existen en un monolito simple.

Si tu problema no es que una parte muy concreta del sistema necesite 10x de escalado frente al resto, igual puedes vivir muchos años más con un monolito que escale vertical y horizontalmente de forma razonable, sin montar una ópera de servicios.

“Con microservicios cada equipo va a toda velocidad”

Ojalá. Eso solo pasa si se cumplen tres condiciones:

Sin eso, lo que consigues es que los equipos se pasen el día esperando a otros equipos, que los contratos cambien sin previo aviso y que los bugs hagan turismo: viajan de un servicio a otro y nadie sabe muy bien en qué frontera se quedaron.

Cuándo un buen monolito es la decisión más moderna que puedes tomar

Hay una idea que sale una y otra vez en artículos, guías y análisis de proyectos reales, y dice algo poco épico pero muy sensato: la mayoría de los equipos estarían mejor con un monolito modular bien hecho que con microservicios.

Piensa en estos escenarios:

Tienes un producto joven, una startup o un equipo pequeño. Sois cuatro personas, el modelo de negocio cambia cada trimestre y la mitad de las historias empiezan con “hemos descubierto que los usuarios en realidad quieren…”. Ahí dividir en 20 servicios es como alquilar 20 pisos cuando aún no sabes en qué ciudad quieres vivir. Más llaves, más puertas, más lío. Menos avanzar.

Tu dominio está borroso. No tienes claros los bounded contexts. Hoy Pedidos y Carrito son una cosa; mañana quizá no. En ese entorno, grabar contratos de red en piedra es una receta para sufrir. Es mucho más barato equivocarte dentro de un monolito y reorganizar módulos que versionar 10 APIs.

Tu equipo no tiene experiencia fuerte en sistemas distribuidos. Nadie se ha peleado aún con tracing distribuido, particiones de red, IAM fino, versionado de contratos a largo plazo. Aprender todo eso está muy bien, pero quizá no a la vez que intentas sacar un producto al mercado con una fecha cerrada.

Tus requisitos de escalado son razonables. No eres Netflix, ni Amazon, ni estás en un Black Friday perpetuo. Con un monolito bien afinado, algo de caching, una base de datos decente y escalado horizontal básico vas sobrado para años.

Y, por último, el temazo: coste operativo . Cada servicio nuevo trae cosas invisibles en el diagrama: más alertas, más despliegues, más logs que revisar, más mantenimientos. Un monolito con un buen pipeline y automatización suele salir más barato de operar que una flota de servicios difíciles de justificar.

En todos estos contextos, dedicar energía a modular bien, a tener tests que valgan para algo, a montar CI/CD y observabilidad mínimamente decentes suele dar mucho más retorno que fragmentar el sistema desde el día uno.

Y entonces, ¿cuándo empiezan a tener sentido de verdad los microservicios?

No hay un semáforo que se ponga en verde y diga “es el momento”. Pero hay señales que se repiten en muchas historias de migración que salieron razonablemente bien.

Empiezan a aparecer patrones de escalado muy desiguales. Una parte del sistema (búsqueda, checkout, streaming, colas de procesamiento) soporta mucho más tráfico que el resto. Escalar todo el monolito solo para aguantar esa pieza empieza a ser caro e ineficiente.

Los ritmos de cambio se disparan en direcciones distintas. Un módulo de negocio necesita cambios semanales, mientras otros tienen que permanecer casi congelados por estabilidad o regulación. Cada despliegue del monolito se convierte en una negociación política: “no toques lo mío, que ahora está auditado”.

La organización ha crecido. Tienes varios equipos reales, con responsables distintos, objetivos distintos, incluso zonas horarias distintas. Forzarles a trabajar todos en el mismo repositorio, con el mismo ciclo de despliegue, genera más fricción que beneficio.

Tus requisitos de disponibilidad y aislamiento empiezan a ser serios. Una caída en un módulo secundario no puede aceptar tumbar la cara de cliente; necesitas separar riesgos por región, por producto, por tipo de usuario.

Y, muy importante: ya has exprimido al monolito. Has arreglado queries, añadido índices, afinado caching, paralelizado donde tenía sentido, limpiado módulos y aun así hay cuellos de botella claros que no se resuelven sin separar cosas.

Cuando varias de estas señales se juntan, los microservicios dejan de ser un capricho arquitectónico y pasan a ser una posible respuesta. Incluso ahí, la experiencia dice: mejor ir poco a poco, usando patrones tipo strangler , extrayendo primero cosas periféricas, midiendo cada paso y manteniendo la posibilidad de volver atrás si algo sale peor de lo esperado.

Decidir la arquitectura sin convertirla en una guerra de bandas

En el fondo, elegir entre monolito, microservicios o alguna variante híbrida no va de quedar por encima en una reunión, va de elegir sabiendo lo que te juegas.

Estas preguntas te pueden servir como una chuleta mental:

Si respondes sin trampas, ni siquiera las que te haces a ti mismo, muchas decisiones pierden el halo de trascendentales.

A veces la respuesta es: “ahora mismo, un monolito modular con buenas prácticas nos llevará mucho más lejos”. Otras será: “hemos llegado al punto en el que extraer este dominio a un servicio separado nos da aire; hagámoslo, pero con un plan y sin romper todo por deporte”.

Menos criaturas mitológicas, más oficio

Monolitos, microservicios, arquitectura hexagonal, eventos, DDD… es fácil que todo esto suene a bestiario medieval. Pero detrás de cada etiqueta hay algo bastante más sencillo: gente intentando hacer sistemas que funcionen, que puedan crecer y que no obliguen a nadie a dormir en la oficina demasiado a menudo.

Hay monolitos viejos que facturan millones al año sin hacer ruido y microservicios muy finos que permiten a empresas moverse a una velocidad impresionante. También hay monolitos imposibles de mantener y enjambres de servicios que son básicamente un monumento al sufrimiento humano.

La clave no es el animal que elijas, sino si lo tratas como lo que es: una herramienta para resolver los problemas de tu contexto, no un tótem que adorar en presentaciones.

Si logras eso, puede que tu sistema nunca salga en un caso de estudio de Netflix… pero, con un poco de suerte, tampoco saldrá en esos hilos de “no hagáis esto jamás, que ya lo hemos sufrido nosotros”.

Y eso, para muchos equipos, ya es una victoria más que digna.

Glosario rápido

Por si algún acrónimo te ha mirado raro, aquí van las traducciones.

Fuentes y referencias

Las fuentes que alimentan este texto, por si quieres profundizar sin tener que aguantarme a mí contándolo.

Sígueme

Escribo y opino sobre tecnología, desarrollo de software y lo que se me pase por la cabeza.