Dos arquitecturas, dos perfiles de proyecto
Diseñamos y construimos backend sobre microservicios cuando el negocio lo justifica y sobre monolito modular cuando esa es la respuesta correcta. La elección decide tres años de coste operativo, velocidad de equipo y deuda técnica acumulada.
En 2026 el péndulo se ha movido. La narrativa por defecto en muchas decisiones técnicas sigue siendo "vamos a microservicios", pero los proyectos que más rendimiento dan en clientes nuestros se han apoyado, más veces de las que se reconoce, en monolito modular bien diseñado. Esta es la matriz de decisión que aplicamos.
El monolito modular en una frase
Una aplicación única, desplegada en un único artefacto, dividida internamente en módulos con fronteras explícitas. Cada módulo expone una API interna; ningún módulo accede al estado de otro sin pasar por esa API. La base de datos puede ser única, con esquemas por módulo, o segmentada con un schema por módulo dentro del mismo motor.
Stack típico en proyectos nuestros: Spring Boot 4 modular · Quarkus con capas internas · arquitectura hexagonal con paquetes por bounded context · PostgreSQL con schemas separados · API REST interna entre módulos · deploy único.
Microservicios en una frase
Múltiples servicios independientes, cada uno con su artefacto desplegable, su base de datos y su ciclo de release. La comunicación entre servicios pasa por HTTP, gRPC o un bus de mensajería. Cada servicio escala, se actualiza y falla por su cuenta.
Stack típico: Spring Boot / Quarkus en cada servicio · API Gateway · Kafka o RabbitMQ · PostgreSQL por servicio · Kubernetes · service mesh · observabilidad consolidada con OpenTelemetry y Grafana.
Dimensión 1: tamaño y madurez del equipo
La regla operativa es clara: si el equipo no llega a ocho ingenieros backend activos, el monolito modular es el default.
Microservicios introducen overhead operativo en proporción inversa al tamaño del equipo. Cada servicio adicional consume ciclos en infraestructura, pipelines, observabilidad, gestión de versiones y depuración inter-servicio. Para un equipo de cuatro ingenieros, tres servicios producen más fricción que una aplicación bien modulada de doscientas mil líneas.
Cuando el equipo crece por encima de doce ingenieros, microservicios facilitan la división por equipos. Esa es la frontera operativa, no la de los doscientos mil usuarios.
Dimensión 2: cohesión del dominio de negocio
Los microservicios entregan su valor cuando los bounded contexts del negocio están bien separados — los equipos comerciales, financieros, logísticos y operativos hablan de cosas distintas, evolucionan a ritmos distintos y tienen ciclos de release independientes.
Cuando el dominio es muy interconectado — la mayoría de las operaciones de negocio cruzan tres o cuatro entidades centrales — un microservicio termina siendo un envoltorio fino de una entidad, con la lógica real dispersa en orquestadores y compensaciones distribuidas. Ese patrón es síntoma de microservicios mal cortados, no de microservicios bien implementados.
En catálogos de productos B2B, gestión de pedidos complejos y dominios financieros pequeños, el monolito modular suele modelar el dominio con menos fricción que tres microservicios artificialmente separados.
Dimensión 3: frecuencia y aislamiento del despliegue
Microservicios ganan cuando partes distintas del sistema necesitan release independiente. Un equipo despliega su servicio cinco veces al día; otro equipo despliega el suyo una vez por semana; ningún despliegue afecta al otro.
En un monolito modular bien construido, los despliegues son únicos y el riesgo se controla con feature flags, canary releases y tests automatizados. Cuando el equipo despliega dos o tres veces al día y los cambios afectan a varios módulos a la vez, esto funciona mejor que coordinar versiones distribuidas.
La frontera práctica: cuando hay equipos paralelos con calendarios de release radicalmente distintos, microservicios. Cuando el negocio empuja el sistema entero a la vez, monolito.
Dimensión 4: necesidad real de escalado independiente
Cada microservicio puede escalar por su lado. Cuando una parte del sistema recibe diez veces el tráfico del resto — generalmente lectura de catálogo, búsqueda, ingestión de datos —, microservicios permiten dimensionar exactamente esa pieza.
En la práctica, la mayoría de aplicaciones B2B medianas no necesitan escalado independiente. El monolito modular escala horizontalmente con réplicas idénticas detrás de un balanceador, y eso resuelve el 95% de los casos por debajo de mil RPS. Por encima, microservicios empiezan a justificarse — siempre que el dominio acompañe.
Dimensión 5: capacidad de operar sistemas distribuidos
La parte más subestimada. Microservicios requieren operación distribuida: distributed tracing, idempotencia en cada operación, compensación cuando una llamada inter-servicio falla, retries con backoff, circuit breakers, gestión de versiones de contratos API.
Equipos sin experiencia previa en estos patrones llegan al sexto mes con un sistema que falla de formas raras y un dashboard que nadie sabe interpretar. La curva de aprendizaje es real y se paga en incidentes de producción.
El monolito modular tiene una operación más sencilla: un sistema, una base de datos, un log centralizado. La complejidad operativa crece de forma lineal con la funcionalidad, no de forma multiplicativa con el número de servicios.
Cuándo cada arquitectura
Resumen accionable:
| Indicador del proyecto | Arquitectura recomendada | |------------------------|--------------------------| | Equipo de 1 a 8 ingenieros | Monolito modular | | Equipo de 12+ con bounded contexts claros | Microservicios | | Dominio muy interconectado | Monolito modular | | Bounded contexts naturalmente separados | Microservicios | | Despliegues coordinados, equipo único | Monolito modular | | Ciclos de release radicalmente distintos por equipo | Microservicios | | Carga por debajo de 1k RPS sin picos asimétricos | Monolito modular | | Carga con asimetría 10× entre partes del sistema | Microservicios | | Equipo sin experiencia previa en sistemas distribuidos | Monolito modular |
Tres proyectos reales, tres rutas distintas
Distribuidor industrial B2B con 45.000 SKUs → monolito modular. Equipo de cinco ingenieros backend, dominio fuertemente interconectado (catálogo, pricing, pedidos, contratos), volumen moderado de tráfico. Spring Boot con cinco bounded contexts en paquetes separados, PostgreSQL con cinco schemas. Resultado a dieciocho meses: p95 de 142 ms en endpoints críticos, deployments diarios sin coordinación inter-equipo, deuda técnica baja medida con SonarQube.
Plataforma de medios con ingesta masiva → microservicios bien acotados. Equipo de quince ingenieros divididos en cuatro escuadras, asimetría de tráfico 12× entre el módulo de ingesta y el resto del sistema. Quarkus para ingesta (startup rápido, native), Spring Boot para el core, Kafka como bus. Resultado: 2,4k RPS sostenidos en ingesta sin afectar al resto, ciclos de release independientes por escuadra, observabilidad consolidada.
E-commerce mediano que migró de microservicios a monolito modular. Caso menos contado. Cliente que había arrancado con seis microservicios sobre un equipo de cuatro ingenieros. A los catorce meses, dos ingenieros se iban a coordinar despliegues cada release. Refactor a un monolito modular Symfony con bounded contexts limpios. Resultado: tiempo de coordinación bajó de tres horas semanales a treinta minutos, errores en producción bajaron 60%, equipo recuperó velocidad de feature delivery.
El patrón intermedio: módulos con potencial de extracción
La mejor decisión arquitectónica de las que hemos tomado en proyectos largos es construir monolito modular diseñado para extracción. Cada módulo tiene su API interna, su esquema de base de datos separado, sus tests aislados. El día que un módulo justifica su propio ciclo de release, se extrae como microservicio sin reescribirlo — porque ya estaba diseñado como uno, dentro del monolito.
Este patrón captura lo mejor de los dos mundos: operación sencilla hoy, opcionalidad para mañana. Es lo que llamamos strangler-ready architecture.
Cómo lo decidimos con el cliente
Cada decisión de arquitectura empieza por entender el negocio antes que el stack: cuántos equipos tiene hoy y a tres años, qué bounded contexts hay realmente, qué partes del sistema reciben tráfico desigual, qué experiencia previa tiene el equipo en sistemas distribuidos. Sobre ese mapa cruzamos las cinco dimensiones y entregamos la recomendación con datos verificables.
Cada decisión deja rastro en un documento de arquitectura que el comité puede leer, contrastar y, si hace falta, rechazar con argumentos. La arquitectura es ejecutable desde el primer commit.
Detrás de cada elección hay un equipo de desarrolladores que cree que la ingeniería seria empieza por entender qué problema se está resolviendo, no por elegir la tendencia del momento. Microservicios cuando aportan, monolito modular cuando es la respuesta correcta. Sistemas listos para producción, no demos de arquitectura.
Si estás evaluando un cambio de arquitectura o arrancando un proyecto nuevo y quieres una decisión defendible antes de comprometer presupuesto, podemos auditar tu caso y entregarte la matriz cruzada con tus datos antes de que la decisión se firme.
