Monolito vs microservicios: cómo elegir según etapa y equipo

Estás a punto de decidir cómo se estructura un producto, y una mala decisión cuesta un año de ingeniería. La pregunta de monolito vs microservicios suele llegar con una moda pegada: una charla de conferencia, alguien contratado de una empresa mucho más grande, el miedo a reescribir más adelante. Rara vez llega con datos sobre tu equipo, tu dominio o tu dolor de deploy.

Este artículo es un marco de decisión, no un glosario. Definimos las tres opciones, incluido el monolito modular que queda entre ambas, y puntuamos cada una por tamaño del equipo, etapa del producto, frecuencia de despliegue y necesidad de escalado. Después ponemos precio a los costes que los diagramas de arquitectura omiten, mostramos cuándo basta una app full-stack en Next.js y planteamos una ruta de migración segura.

Nuestra respuesta por defecto es corta. Empieza con un monolito modular, haz cumplir sus límites en el código y separa un módulo solo cuando un dolor medido justifique una frontera de red. El resto del artículo muestra cómo medir ese dolor.

Monolito vs microservicios: definiciones y término medio#

El debate de monolito vs microservicios se estanca cuando cada bando entiende algo distinto con las mismas palabras. Aquí va el vocabulario común, en definiciones que puedes citar en una revisión de diseño.

Qué es un monolito#

Un monolito es una aplicación construida y desplegada como una sola unidad: un código base, un artefacto de build y, normalmente, una base de datos. Una llamada de la lógica de facturación a la lógica de pedidos es una llamada a función dentro de un proceso. Devuelve un valor o lanza una excepción, y comparte transacción con quien la llama.

Monolito no significa desordenado. La forma de despliegue y la estructura interna son decisiones separadas, y la mayoría de los argumentos contra los monolitos son en realidad argumentos contra los que no tienen estructura.

Qué son los microservicios#

Martin Fowler y James Lewis describen los microservicios como un conjunto de servicios pequeños, cada uno en su propio proceso y comunicados con mecanismos ligeros, a menudo una API HTTP. Los servicios se construyen alrededor de capacidades de negocio y se despliegan de forma independiente. La palabra que carga el peso es independiente.

Si dos servicios siempre deben salir juntos, tienes un monolito distribuido: los costes de ambos estilos y los beneficios de ninguno. Además, cada microservicio real es dueño de sus datos. No hay tablas compartidas ni joins entre servicios.

El monolito modular, el punto medio#

Un monolito modular se despliega como una unidad pero se organiza en módulos con límites explícitos. Cada módulo expone una API pública pequeña y oculta sus detalles internos. Los demás módulos nunca acceden a sus archivos privados ni a sus tablas.

Esto te da la mayor parte de lo que los equipos buscan en los microservicios: propiedad clara, razonamiento local y piezas que se pueden probar por separado. Se salta la red. Y deja una puerta abierta, porque un módulo con un límite limpio es un servicio que puedes extraer después.

Monolith First, de Fowler, defiende este punto de partida. Según su relato, los sistemas de microservicios exitosos que conocía empezaron como monolitos que crecieron demasiado y luego se dividieron, mientras que los sistemas diseñados como microservicios desde el primer día solían acabar en serios problemas. Su razonamiento es que no puedes trazar buenos límites de servicio antes de conocer el dominio, y un límite equivocado a través de la red es caro de mover.

Tabla de decisión: monolito vs microservicios#

Usa la tabla como primer filtro. Los rangos son reglas generales de nuestros proyectos y de la práctica común del sector, no umbrales medidos, así que léelos como direcciones y no como líneas.

Lee la tabla por dolor, no por moda. Si no puedes nombrar una fila donde los microservicios ganen claramente hoy para ti, la opción por defecto se mantiene. Los factores siguientes explican cómo leer cada fila.

Tamaño del equipo y propiedad#

Los microservicios resuelven un problema de coordinación entre equipos, no un problema de código. Cuando cuarenta ingenieros comparten un pipeline de deploy, se bloquean entre sí, y los límites de servicio permiten que cada equipo despliegue solo. Cuando lo comparten seis, el problema de coordinación apenas existe, y pagas el sobrecoste por nada.

Una prueba útil es la propiedad. ¿Puede un equipo ser dueño completo de un servicio, incluidas sus guardias, sus dashboards y sus datos? Si no, la división crea servicios huérfanos, peores que un módulo compartido.

Etapa del producto e incertidumbre#

Los productos tempranos cambian de forma cada pocas semanas. Las entidades se fusionan, los flujos desaparecen, un nuevo segmento de clientes reescribe el modelo de datos. En un monolito un cambio transversal es un pull request y un deploy. Entre servicios son varias releases coordinadas, contratos versionados y una migración de datos.

Por eso microservicios vs monolito para startups rara vez es una decisión reñida. El recurso escaso de una startup es la velocidad de aprendizaje, y un sistema distribuido grava cada experimento. Cuando el dominio se estabiliza y los límites se ven en el código, la pregunta se reabre.

Frecuencia de despliegue y necesidades de escalado#

Son dos disparadores distintos. La frecuencia de despliegue importa cuando un módulo debe salir muchas veces al día mientras otro cambia cada trimestre bajo revisión estricta, y acoplar sus releases perjudica a ambos. El escalado importa cuando un módulo, como el procesamiento de imágenes, la indexación de búsqueda o la generación de informes, necesita mucha más CPU que el resto.

Antes de separar por escala, prueba las opciones más baratas. Ejecuta más réplicas del monolito, mueve el trabajo pesado a una cola y a un proceso worker construido desde el mismo código base, añade una caché o una réplica de lectura. Un worker con otro punto de entrada no es un microservicio, y a menudo resuelve el problema. Para la parte de infraestructura, consulta nuestra guía de escalabilidad en la nube con AWS, GCP y Azure.

Ejemplo práctico: un portal de pedidos B2B#

Tomemos un caso ilustrativo: siete ingenieros construyen un portal de pedidos B2B con listas de precios personalizadas y sincronización con un ERP. El equipo es un solo squad, el dominio aún se mueve, las releases salen cada semana y el único trabajo pesado es la sincronización nocturna con el ERP. Según la tabla, el tamaño del equipo dice monolito o modular, la etapa dice modular, el despliegue dice salir juntos y el escalado dice worker. La respuesta es un monolito modular con la sincronización del ERP como worker de cola desde el mismo código base.

Los costes ocultos de los microservicios#

Los diagramas de microservicios muestran cajas y flechas. No muestran las horas de ingeniería detrás de cada flecha. Tres costes aparecen en casi todos los proyectos que adoptan el estilo, y los equipos tienden a subestimar los tres.

El versionado merece una mirada más atenta. Cuando el servicio A llama al servicio B, B no puede cambiar una respuesta sin un plan. Mantienes campos antiguos, ejecutas dos versiones durante un rollout y escribes contract tests para los consumidores. En un monolito el compilador encuentra por ti al llamador roto.

Observabilidad y depuración entre servicios#

En un monolito, un stack trace te dice qué pasó. Entre servicios, una petición de usuario toca varios procesos, y la traza existe solo si cada salto propaga un correlation ID. Necesitas tracing distribuido (OpenTelemetry es el estándar habitual), logs estructurados que compartan un ID de petición, métricas por servicio y alertas que señalen el salto que falla en lugar del síntoma en el borde.

Sin esto, el primer incidente en producción se convierte en una búsqueda entre cinco flujos de logs. El coste no es la licencia de la herramienta. Es la disciplina de instrumentar todos los servicios de la misma forma.

Petición entre servicios

1. 01PeticiónUna acción de usuario entra al sistema
2. 02GatewayInicia el trace ID

• AServicio de pedidosSalto de red, trace ID transmitido
  1. Servicio de facturaciónEl salto puede agotar el tiempo
• BServicio de facturaciónSalto de red, trace ID transmitido
  1. TimeoutEl trace ID localiza el salto fallido
• CServicio de inventarioSalto de red, trace ID transmitido

En un monolito la petición queda en un proceso; en microservicios cruza saltos de red donde un timeout exige tracing para localizarlo

Consistencia de datos sin transacciones compartidas#

Un monolito con una sola base de datos te da transacciones ACID. Cobrar la tarjeta, reservar stock y crear la factura se confirman todos o ninguno. Si divides esos pasos en servicios con sus propias bases de datos, esa garantía desaparece.

La sustituyes por sagas, tablas outbox, reintentos y acciones compensatorias. Cada una es un patrón que debes diseñar, probar y operar. La consistencia eventual también se filtra al producto: un cliente ve un pedido sin factura durante unos segundos, y soporte tiene que saber por qué. Los informes también cambian, porque un join entre servicios se convierte en un pipeline de datos.

DevOps y sobrecarga de plataforma#

Cada servicio necesita su propio pipeline, imagen de contenedor, configuración, secretos, health checks, reglas de escalado, dashboards y cobertura de guardia. El desarrollo local se vuelve más pesado, porque ejecutar diez servicios en un portátil no es lo mismo que ejecutar uno. Los contract tests y los entornos de staging parecidos a producción pasan de opcionales a obligatorios.

Un ejemplo ilustrativo. Un equipo de ocho ingenieros divide un producto en doce servicios. Ahora mantienen doce pipelines, doce conjuntos de alertas y doce rutas de actualización de imágenes base, con las mismas ocho personas. Los equipos en esta situación suelen terminar dedicando ingenieros a una función de plataforma, y ese coste es real aunque nunca aparezca en el diagrama.

Cuándo basta un monolito en Next.js#

El consejo abstracto es fácil. Aquí va el caso concreto del stack que más construimos, una aplicación Next.js, y el punto en que deja de bastar.

Qué puede soportar una app Next.js#

Next.js es un framework full-stack. Los server components renderizan páginas, los route handlers exponen endpoints HTTP, las server actions gestionan mutaciones y el middleware se ejecuta antes de que una petición llegue a una ruta. La documentación de Next.js cubre cada uno. Detrás hay un cliente de base de datos, autenticación, tareas programadas y código de integración.

Para un portal B2B, una tienda con precios personalizados o un dashboard SaaS, una sola app Next.js suele llevar la interfaz, la API y la lógica de negocio en un solo deploy. Las decisiones de renderizado y rendimiento siguen importando dentro de esa app, y las tratamos en nuestro artículo sobre sitios ultrarrápidos con Next.js, Astro y Remix.

Donde deja de bastar: trabajos que sobreviven a una petición, cómputo pesado de CPU y cargas en otro lenguaje. Eso pasa a un proceso worker, todavía en el mismo repositorio, mucho antes de justificar un servicio aparte.

Mantener los límites de módulo en el código#

El monolito se mantiene sano cuando los límites los hacen cumplir las herramientas, no la buena voluntad. Mantén las rutas delgadas: leen la entrada, llaman a un módulo y renderizan. Pon la lógica de negocio y el acceso a datos en módulos, y deja que otros módulos importen solo desde el index.ts de un módulo.

src/
  app/                  # rutas: leen la entrada, llaman a módulos, renderizan
  modules/
    billing/
      index.ts          # API pública, el único archivo importable
      create-invoice.ts
      internal/
        invoice-repository.ts
    orders/
      index.ts
      place-order.ts

El módulo billing oculta su repositorio tras una API pública:

// src/modules/billing/internal/invoice-repository.ts
export type Invoice = {
  id: string;
  orderId: string;
  amountCents: number;
  status: "open" | "paid";
};

// Almacén en memoria para el ejemplo. Sustitúyelo por tu cliente de base de datos.
const invoices = new Map<string, Invoice>();

export async function saveInvoice(invoice: Invoice): Promise<Invoice> {
  invoices.set(invoice.id, invoice);
  return invoice;
}

// src/modules/billing/create-invoice.ts
import { randomUUID } from "node:crypto";
import { saveInvoice, type Invoice } from "./internal/invoice-repository";

export async function createInvoice(orderId: string, amountCents: number): Promise<Invoice> {
  return saveInvoice({ id: randomUUID(), orderId, amountCents, status: "open" });
}

// src/modules/billing/index.ts
// API pública del módulo billing. Nada más es importable desde fuera.
export { createInvoice } from "./create-invoice";
export type { Invoice } from "./internal/invoice-repository";

El módulo orders llama a la API pública y a nada más:

// src/modules/orders/place-order.ts
import { createInvoice } from "@/modules/billing"; // permitido: API pública

export async function placeOrder(orderId: string, totalCents: number) {
  const invoice = await createInvoice(orderId, totalCents);
  return { orderId, invoiceId: invoice.id };
}

Después haz que el paso de lint lo haga cumplir. Esta entrada de configuración flat de ESLint bloquea cualquier import que llegue más allá de la raíz de un módulo. Añádela al array de tu configuración flat existente.

// eslint.config.mjs: añade este objeto al array de tu configuración flat existente
{
  files: ["src/**/*.{ts,tsx}"],
  rules: {
    "no-restricted-imports": ["error", {
      patterns: [{
        group: ["@/modules/*/*"],
        message: "Import from the module root (index.ts) only."
      }]
    }]
  }
}

Aplica la misma regla a los datos. Billing es dueño de sus tablas, y los demás módulos llaman a createInvoice en lugar de leer la tabla invoices. Cuando más adelante extraigas billing, su API pública se convierte en el contrato del servicio, y la regla de lint ya te habrá dicho quién lo llama.

Señales de que toca separar#

Estas son las señales que buscamos. Una sola rara vez basta. Dos o tres juntas, con un límite que ya puedas nombrar, justifican una separación.

• El calendario de releases de otro equipo bloquea repetidamente tus deploys independientes
• Un módulo necesita un perfil de escalado muy distinto y las réplicas más un worker no lo resolvieron
• Un módulo está en su propio perímetro de cumplimiento, como datos de tarjetas de pago o historiales médicos
• El equipo ha superado lo que unos pocos squads pueden coordinar en un solo código base
• Un módulo necesita otro runtime o lenguaje, como un servicio de modelos en Python
• Hoy puedes dibujar el límite y nombrar su API pública

Fíjate en lo que falta en la lista: que el código parezca grande, o que alguien nuevo prefiera microservicios. El tamaño es un problema de modularidad, y los límites lo arreglan. Una red no.

Migrar con el patrón strangler#

Si las señales están ahí, no reescribas. El patrón strangler de Fowler sustituye un sistema pieza a pieza: el código nuevo crece alrededor del viejo hasta que este puede retirarse. El sistema sigue atendiendo a los clientes todo el tiempo.

1. Mapea los módulos

   Lista los módulos, sus llamadores y las tablas que toca cada uno. Una dependencia que no puedes dibujar es una costura que aún no puedes cortar.

2. Elige la costura

   Escoge un módulo con una API pública limpia, datos propios y una razón concreta para separarlo.

3. Pon un proxy delante

   Enruta todo el tráfico por un reverse proxy o gateway que siga apuntando al monolito.

4. Extrae y ejecuta ambos

   Construye el servicio, copia sus datos y desplaza el tráfico poco a poco comparando respuestas.

5. Elimina el código viejo

   Borra el módulo del monolito y elimina sus tablas tras una ventana de retención.

Elegir el primer servicio a extraer#

La primera extracción enseña a tu equipo todo el flujo de trabajo, así que elige una costura valiosa y de bajo riesgo. Los buenos candidatos tienen pocas dependencias entrantes, una API pública clara, datos propios y una razón concreta para separarse, como escala, cumplimiento o cadencia de releases.

El envío de notificaciones, la generación de PDF, la indexación de búsqueda, el procesamiento de medios y la sincronización con ERP son primeros servicios típicos. Los malos candidatos son las entidades que lee todo módulo, como usuarios o pedidos, y cualquier cosa que necesite una transacción con otros módulos.

Enrutar el tráfico y retirar el código viejo#

Pon un reverse proxy o gateway delante del monolito antes de cambiar nada. Empieza enviando todo el tráfico al monolito y luego desplaza una ruta cada vez al nuevo servicio, primero una pequeña parte y después todo. El rollback es un cambio de configuración, no un deploy.

Patrón strangler

1. 01Todas las rutas al monolitoEl proxy envía los módulos A, B, C a una app
2. 02Se desplaza AServicio A activo, el monolito conserva B y C
3. 03Se desplaza BServicio B activo, el monolito solo C
4. 04Monolito reducidoServicios A y B, monolito pequeño con C

El patrón strangler: un proxy envía primero todas las rutas al monolito y luego las desplaza una a una a nuevos servicios mientras el monolito se reduce

Los datos son lo difícil. El nuevo servicio recibe su propio almacén, llenado con una copia única y mantenido sincronizado hasta que cambias lecturas y escrituras a la vez. Luego viene el paso que los equipos se saltan: borrar el módulo viejo y, tras una ventana de retención, sus tablas. Un monolito estrangulado que conserva código muerto es más difícil de leer que antes de empezar.

Restricciones de integración con ERP y CRM#

Las integraciones moldean la arquitectura más que las preferencias. Las APIs de ERP y CRM suelen tener límites de tasa, ser lentas y orientadas a lotes, y otra persona controla su disponibilidad y su esquema. Uses monolito o servicios, debes aislarlas. Nuestro artículo sobre integraciones de APIs y sistemas legacy para sitios web empresariales profundiza en la parte legacy.

La integración como módulo propio#

Trata cada ERP o CRM como un módulo con una interfaz en los términos de tu dominio, como syncCustomer o getStockLevel, nunca en nombres de campo del proveedor. El módulo se encarga de la autenticación y la renovación de tokens, el manejo de límites de tasa, el mapeo entre tu modelo y el del proveedor, la caché de lecturas lentas y un registro de auditoría. El resto de la app nunca importa el SDK del proveedor.

Esto rinde dos veces. Cuando el proveedor cambia su API, cambia un solo módulo. Cuando separes más adelante, este módulo suele ser el primer servicio, porque ya tiene su propio perfil de fallo y de escalado.

Webhooks, colas e idempotencia#

Los webhooks llegan al menos una vez, desordenados y en ráfagas. Verifica la firma, guarda el evento en bruto, responde rápido con un estado 2xx y procesa en un worker. Usa el ID del evento como clave de idempotencia para que una repetición no cree un pedido duplicado ni una segunda factura.

Las llamadas salientes a un ERP con límite de tasa necesitan una cola con concurrencia controlada, reintentos con backoff exponencial y jitter, y una dead-letter queue para los eventos que siguen fallando. Cachea lo que cambia despacio, como listas de precios y niveles de stock, y muestra la antigüedad de la caché en tu admin para que soporte sepa lo que vio el cliente.

Serverless, edge y headless en breve#

Los líderes de ingeniería suelen listarlos junto a la elección entre monolito y microservicios. No son alternativas a ella. Responden a preguntas distintas, dónde se ejecuta el código y cómo se entrega el frontend, y un mismo monolito puede ser serverless, renderizado en el edge y headless a la vez.

Elígelos según el problema que tengas delante. Serverless encaja con trabajo corto y con picos, como los handlers de webhooks. El edge encaja con personalización y redirecciones que deben ejecutarse cerca del visitante. Headless encaja con equipos donde editores de contenido y desarrolladores necesitan avanzar de forma independiente, y comparamos las herramientas en nuestra guía de CMS headless y arquitectura desacoplada.

Ninguno elimina la necesidad de límites de módulo. Un despliegue serverless de una app enredada sigue siendo una app enredada.

Por dónde empezar#

Puedes empezar esta semana sin reescribir ni reorganizar nada. Haz tres cosas en orden.

1. Audita los límites de módulo. Lista tus tres áreas más grandes, quién importa qué y dónde viven las dependencias circulares. Un límite que no puedes dibujar no está listo para extraerse.
2. Mide el dolor de deploy. Registra el lead time desde el merge hasta producción, con qué frecuencia las releases se bloquean entre sí y cuántos rollbacks haces al mes. Los números ganan a las opiniones en una reunión de arquitectura.
3. Nombra el dolor que resolvería una separación. Si no puedes, añade la regla de lint anterior y sigue desplegando desde un solo código base.

Si quieres una segunda opinión, hacemos revisiones de arquitectura para equipos B2B que construyen sobre Next.js y aplicaciones a medida. Nuestra página de soluciones muestra cómo las construimos y las operamos, y puedes contactarnos para reservar una revisión de tu estructura actual.

Preguntas frecuentes#