⏱️ Tiempo de lectura estimado: 7 minutos

Microservicios vs Monolito: cuándo cada uno tiene sentido

Era un martes a las 11pm. Teníamos el sistema caído, tres servicios apuntando a versiones incompatibles de una misma API, y el único que entendía el orquestador de mensajes estaba de vacaciones en Cancún. Habíamos migrado a microservicios hacía seis meses porque "era lo que hacía Netflix". Spoiler: no somos Netflix.

Esa noche aprendí algo que ningún artículo de Medium me había dicho con honestidad: la arquitectura correcta no es la más moderna, es la que te deja dormir. Y eso depende de contexto, equipo, y una dosis honesta de autocrítica sobre dónde realmente estás parado como organización.

Vamos a hablar de esto sin rodeos.

El monolito no es una mala palabra

Algo que pasa mucho en entrevistas técnicas: alguien menciona que su sistema actual es un monolito y lo dice casi con vergüenza, como si fuera una confesión. Como si tener todo en un solo deploy fuera señal de que no leíste suficientes posts de arquitectura.

Pero mirá esto desde otro ángulo. Un monolito bien estructurado —con módulos claros, separación de responsabilidades, y buenas prácticas de código— es más fácil de razonar, más fácil de testear en conjunto, y más fácil de debuggear cuando algo explota. No tenés que rastrear una request a través de ocho servicios y cuatro colas de mensajes para entender por qué falló el checkout.

En mi experiencia, la mayoría de los equipos de menos de 15-20 devs están mejor con un monolito modular. No porque los microservicios sean malos, sino porque el overhead operacional de mantener múltiples servicios independientes —con su propio CI/CD, su propio monitoreo, su propio versionado de contratos— consume una energía brutal que en equipos pequeños es simplemente dinero tirado.

El monolito modular: lo mejor de ambos mundos (en serio)

Ahora bien, "monolito" no significa "todo mezclado en un archivo de 40.000 líneas". Hay una diferencia enorme entre un monolito legacy sin estructura y uno diseñado intencionalmente con módulos bien definidos.

La idea es simple: organizás tu código en dominios de negocio claros —usuarios, pagos, inventario, lo que sea— con interfaces explícitas entre ellos. Cada módulo podría, en teoría, convertirse en un servicio independiente más adelante. Pero mientras tanto, todo corre junto, se despliega junto, y podés hacer un refactor sin necesitar un documento de RFC de 12 páginas.

Esto es lo que Shopify hizo durante años. Y Basecamp. Y Stack Overflow. Y funcionó.

Cuándo los microservicios sí tienen sentido

Ojo que no estoy diciendo que los microservicios sean un error. Estoy diciendo que tienen un costo real, y ese costo vale la pena solo en ciertos contextos.

Los microservicios empiezan a tener sentido cuando:

Tenés equipos que necesitan autonomía real. Si tenés cinco equipos de 8 personas trabajando sobre el mismo codebase, el monolito se convierte en un cuello de botella social antes que técnico. Los merge conflicts, las dependencias cruzadas, la coordinación de releases... todo eso mata velocidad. Ahí la separación por servicios no es un lujo, es una necesidad organizacional.

Tenés necesidades de escala radicalmente distintas por componente. Si tu servicio de procesamiento de imágenes necesita escalar x100 durante eventos especiales pero tu módulo de autenticación no, tiene sentido separarlos. Escalar todo el monolito para atender una sola parte es caro y torpe.

Tenés equipos con la madurez operacional para sostenerlo. Y acá viene la parte incómoda: los microservicios requieren una cultura DevOps madura. Observabilidad seria, tracing distribuido, gestión de fallos en cascada, contratos de API versionados, service discovery... Si tu equipo todavía está batallando con cómo hacer un buen pipeline de CI/CD, agregar complejidad distribuida encima es como construir el segundo piso antes de tener los cimientos.

La trampa del "eventual consistency"

Algo que nadie te cuenta cuando te venden microservicios es lo difícil que se vuelve mantener consistencia de datos entre servicios. En un monolito con una base de datos, una transacción es una transacción. En un sistema distribuido, de repente estás manejando sagas, eventos de compensación, y estados intermedios que pueden durar segundos o minutos.

No es imposible. Pero es un problema genuinamente difícil. Y la mayoría de los sistemas de negocio no necesitan esa complejidad. Si tu caso de uso más crítico es "el usuario hace un pedido y tiene que quedar registrado correctamente", una transacción ACID en un monolito resuelve eso de forma elegante y sin dramas.

La decisión real: empieza por el equipo, no por la tecnología

Esto es algo que me ha funcionado cuando tengo que tomar este tipo de decisiones: antes de hablar de arquitectura, hablo de equipo.

¿Cuántas personas van a mantener esto? ¿Tienen experiencia operando sistemas distribuidos? ¿Hay un equipo de plataforma dedicado o los mismos devs de producto van a lidiar con la infraestructura? ¿Cuánto tiempo tienen para aprender mientras construyen?

Las respuestas a esas preguntas determinan más la arquitectura correcta que cualquier consideración técnica pura.

Hay un concepto que me gusta mucho de Gregor Hohpe: la arquitectura exitosa no es la más elegante en papel, es la que puede ser sostenida por el equipo que la construye. Una arquitectura brillante en manos de un equipo sin contexto es peor que una arquitectura mediocre bien entendida por todos.

El patrón que suelo recomendar

Si tuviese que dar un consejo concreto a alguien arrancando un proyecto nuevo: empezá con un monolito modular. Diseñá bien los límites de tus módulos pensando en dominios de negocio. Usá interfaces claras entre ellos. Y cuando —no si, cuando— algún módulo específico necesite escalar o ser desarrollado por un equipo separado, extraelo como servicio en ese momento, con toda la información real de por qué lo estás haciendo.

Eso es lo que Martin Fowler llama "MonolithFirst". Y tiene mucho más sentido que diseñar para una escala que quizás nunca llegue.

Antes de irte

Si estás en medio de una migración a microservicios que se siente más a un desastre que a una mejora, no estás solo. Esa sensación de que la arquitectura te está controlando a vos en vez de al revés es más común de lo que la gente admite en público. A veces la decisión más valiente es pausar, evaluar honestamente, y reconocer que el contexto cambió.

La arquitectura perfecta no existe, pero la arquitectura adecuada para tu equipo hoy sí. Encontrala ahí, no en el último post viral de Hacker News.