Monolito vs microservicios: por qué tu proyecto probablemente no necesita lo segundo

Seguro que has oído la historia. Una startup arranca con un monolito, crece, se ahoga, migra a microservicios y todo funciona. Netflix lo hizo. Amazon lo hizo. Spotify lo hizo.

Lo que no se cuenta tanto es el contexto. Netflix migró cuando tenía cien millones de usuarios y miles de ingenieros. Tu proyecto probablemente no tiene ni lo uno ni lo otro. Y eso cambia la ecuación por completo.

En el debate monolito vs microservicios, el error más frecuente no es elegir mal la arquitectura. Es elegirla demasiado pronto, basándose en lo que hacen empresas que no se parecen en nada a la tuya.

Qué es cada cosa (sin rodeos)

Un monolito es una aplicación donde todo el código vive junto: la lógica de negocio, la gestión de usuarios, los pagos, las notificaciones. Se despliega como una sola unidad. Cuando actualizas una parte, despliegas todo.

Los microservicios dividen esa aplicación en servicios independientes. Cada servicio hace una cosa, tiene su propia base de datos y se comunica con los demás a través de APIs o mensajería. Se despliegan por separado.

Hasta aquí, la teoría. La práctica es donde las cosas se complican.

Lo que el monolito hace bien (y nadie quiere admitir)

El monolito tiene mala prensa. Suena a antiguo, a limitado, a "no escala". Pero hay razones sólidas por las que sigue siendo la mejor opción para la mayoría de proyectos.

Simplicidad operativa. Una base de código, un despliegue, una base de datos. No necesitas orquestadores de contenedores, service mesh, API gateways ni herramientas de trazabilidad distribuida. Tu equipo puede centrarse en construir producto en lugar de mantener infraestructura.

Velocidad de desarrollo. En un monolito, refactorizar es cambiar código en el mismo repositorio. No hay que coordinar cambios entre cinco servicios, versionar APIs ni gestionar contratos de comunicación. Para equipos pequeños (menos de 10-15 desarrolladores), esta simplicidad se traduce directamente en velocidad.

Debugging directo. Cuando algo falla en un monolito, el stack trace te dice exactamente dónde. En microservicios, un error puede implicar rastrear llamadas entre seis servicios, con logs distribuidos y latencias de red que complican el diagnóstico.

Transacciones simples. Si tu operación necesita actualizar tres tablas de forma atómica, en un monolito es una transacción de base de datos. En microservicios, es un patrón saga con compensaciones, idempotencia y gestión de fallos parciales. La complejidad se multiplica.

Coste. Un monolito corre en un servidor o un cluster sencillo. Los microservicios necesitan infraestructura para cada servicio, balanceadores, colas de mensajes, registros de servicios. Según datos de InfoQ, el coste operativo de una arquitectura de microservicios puede ser entre 3 y 10 veces mayor que el de un monolito equivalente en las fases iniciales.

Lo que los microservicios hacen bien (cuando los necesitas)

Los microservicios no son una moda sin fundamento. Resuelven problemas reales. Pero problemas que aparecen en una escala y complejidad específicas.

Escalado independiente. Si el 90% de tu tráfico va a un módulo concreto (búsqueda, por ejemplo), con microservicios puedes escalar solo ese servicio en lugar de replicar toda la aplicación. En un monolito, escalas todo o nada.

Equipos autónomos. Cuando tienes 50, 100 o 200 desarrolladores, un monolito se convierte en un cuello de botella organizativo. Todo el mundo trabaja en el mismo código, los conflictos de merge son constantes y los despliegues se coordinan con dolor. Los microservicios permiten que cada equipo sea dueño de su servicio y despliegue a su ritmo.

Tecnología heterogénea. Cada servicio puede usar el lenguaje y la base de datos que mejor encaje con su problema. El servicio de búsqueda puede usar Elasticsearch, el de pagos puede correr en Java con garantías de tipo estrictas, y el de notificaciones puede ser una función serverless. En un monolito, todo comparte stack.

Aislamiento de fallos. Si un microservicio cae, los demás pueden seguir funcionando (si están bien diseñados). En un monolito, un fallo en un módulo puede tumbar toda la aplicación. Esto es crítico en sistemas donde la disponibilidad es un requisito de negocio.

Las preguntas que deberías hacerte

Antes de elegir entre monolito y microservicios, responde esto con honestidad:

¿Cuántas personas hay en tu equipo de desarrollo? Si son menos de 10-15, un monolito te va a dar más velocidad. El overhead organizativo de los microservicios no se justifica con equipos pequeños. No es una opinión: es el patrón que se repite en la industria.

¿Tu producto ya tiene tracción? Si estás validando una idea, construyendo un MVP o en las primeras fases de crecimiento, el monolito te permite iterar más rápido. Puedes migrar después, cuando tengas datos reales sobre dónde están los cuellos de botella. Invertir en microservicios antes de tener usuarios es optimizar para problemas que quizá nunca lleguen.

¿Tienes problemas reales de escalado? "Necesitamos escalar" y "vamos a necesitar escalar algún día" son frases muy distintas. Si tu monolito maneja el tráfico actual sin sudar, no necesitas microservicios.

Un monolito bien construido con Django o frameworks similares puede servir millones de peticiones al día. No es una limitación: es una solución que funciona.

¿Tu equipo tiene experiencia en sistemas distribuidos? Los microservicios no eliminan la complejidad: la trasladan de la aplicación a la infraestructura. Necesitas gente que sepa de networking, observabilidad, orquestación de contenedores, patrones de resiliencia y debugging distribuido. Si tu equipo no tiene esa experiencia, la curva de aprendizaje va a frenar el desarrollo durante meses.

¿Puedes asumir el coste operativo? Más servicios significa más infraestructura, más monitorización, más alertas, más puntos de fallo. Según Martin Fowler, los microservicios tienen un "premium" de complejidad que solo se justifica cuando la alternativa (el monolito) ya no puede absorber el crecimiento.

El camino intermedio que nadie menciona

La conversación monolito vs microservicios suele presentarse como una decisión binaria. Monolito o microservicios. Blanco o negro. Pero hay un punto intermedio que funciona muy bien para la mayoría de proyectos en crecimiento: el monolito modular.

Un monolito modular es una aplicación que se despliega como una sola unidad, pero cuyo código está organizado en módulos independientes con límites claros. Cada módulo tiene su propia lógica, sus propios modelos de datos y una interfaz bien definida con el resto.

La ventaja: tienes la simplicidad operativa del monolito con la separación lógica que después facilita extraer servicios si realmente lo necesitas. No es un compromiso: es una estrategia.

Shopify es un caso conocido. Según su propio equipo de ingeniería, apostaron por modularizar su monolito en lugar de migrar a microservicios. Procesan miles de millones en transacciones con esta arquitectura. Si les funciona a ellos, probablemente funcione para tu proyecto.

Cuándo tiene sentido migrar

Si ya tienes un monolito y estás considerando microservicios, hay señales claras de que el momento ha llegado:

Los despliegues son un cuello de botella. Varios equipos necesitan desplegar a distintos ritmos y el monolito lo impide. Las colas de merge crecen y los despliegues se retrasan días.

Un módulo necesita escalar muy por encima del resto. Si el 5% de tu código consume el 80% de los recursos, tiene sentido extraerlo como servicio independiente. Pero solo ese módulo, no todo.

El monolito se ha vuelto inmanejable en términos de deuda técnica. La base de código es tan grande y está tan acoplada que ningún cambio es seguro. Antes de migrar a microservicios, valora si refactorizar el monolito no resuelve el problema con menos riesgo.

Tu organización ha crecido hasta el punto de necesitar equipos autónomos. Si tienes 40+ desarrolladores y la coordinación dentro del monolito ya no funciona, la división en servicios puede ser la respuesta organizativa (no solo técnica).

Si ninguna de estas señales encaja, probablemente no necesitas microservicios. Y eso está bien.

La arquitectura no es una declaración de intenciones

Elegir monolito no es admitir que tu proyecto es pequeño. Elegir microservicios no demuestra que tu equipo es moderno. La arquitectura es una herramienta, no una identidad.

Lo que importa es que la decisión se tome con datos, no con modas. Que responda a problemas reales de tu equipo y tu producto, no a lo que hizo Netflix hace diez años.

Empieza simple. Construye un monolito modular, bien estructurado, con límites claros entre módulos. Cuando los datos te digan que necesitas distribuir, tendrás una base sólida desde la que hacerlo.

Y si ese momento nunca llega, habrás ahorrado meses de complejidad innecesaria.