Un CTO te dice que hay que ir a microservicios. Lo ha leído, lo ha oído en una conferencia, lo ha visto en el organigrama de una empresa diez veces más grande que la tuya. Suena a arquitectura moderna. Suena a escalar. Suena a que el monolito es cosa del pasado.
El problema no es el monolito. El problema es un monolito desordenado que nadie se atreve a tocar. Trocearlo en diez servicios no arregla eso: lo multiplica. Cada corte es un contrato, un despliegue, un fallo de red, una alerta a las tres de la mañana. Si no tienes el equipo ni el tráfico para pagar esa factura, no estás modernizando. Estás comprando complejidad.
Este artículo te da el criterio que usamos en Truman cuando un cliente de València —o de fuera— nos pide desarrollo web a medida y aparece la palabra microservicios. Qué es monolito vs microservicios de verdad, cuándo un monolito bien hecho gana, y cuándo sí conviene trocear. Sin ideología de framework.
Qué significa de verdad monolito vs microservicios
Un monolito no es «todo el código en un PHP de 2004». Es una aplicación que se despliega como una unidad, comparte base de datos y proceso, y resuelve varios dominios en el mismo repo. Puede estar modularizado, con bounded contexts claros y tests. Puede ser un desastre. La forma de empaquetarlo no define la calidad.
Un microservicio es un proceso que se despliega solo, tiene su propio almacén de datos —o al menos su propio contrato de persistencia— y se habla con los demás por red. Si tus «microservicios» comparten la misma base y se despliegan juntos, no tienes microservicios. Tienes un monolito distribuido: lo peor de los dos mundos.
La decisión no es estética. Es de equipo, de dominio y de fallo. ¿Cuántas personas tocan el código cada semana? ¿Hay un módulo que escala de forma distinta al resto? ¿Puedes permitirte que un servicio caiga sin tumbar el checkout? Si no puedes responder eso con números o con incidentes reales, todavía no estás eligiendo arquitectura. Estás eligiendo una etiqueta.
En proyectos como Klapper —plataforma de venta de entradas, no una web corporativa— el backend tiene lógica de aforo, cobro y roles. Eso pide módulos claros. No pide, de salida, ocho repositorios y un service mesh. En EIM Jeanología el peso estaba en una web a medida con contenido e integraciones, no en un ecosistema de equipos independientes. El tamaño del problema manda.
Cuándo un monolito bien hecho gana
Gana cuando el producto cabe en la cabeza de un equipo pequeño. Tres a ocho personas que se hablan cada día. Un dominio que todavía se está descubriendo. Un tráfico que un solo proceso bien cacheado y una base bien indexada aguanta sin drama. Eso cubre la mayoría de webs a medida y de plataformas de negocio que vemos en el estudio.
Gana también cuando el coste de un error de consistencia es alto. Pedido + stock + factura en la misma transacción. En un monolito es un BEGIN/COMMIT. En microservicios es saga, cola, compensación y un estado intermedio que el cliente no entiende. Si tu negocio no tiene un equipo de plataforma, esa saga la vas a depurar tú un viernes.
| Señal | Monolito | Microservicios |
|---|---|---|
| Equipo de 1 a 8 personas | Encaja | Sobrecoste |
| Dominio aún cambiando cada sprint | Más barato mover | Contratos rígidos pronto |
| Un módulo con carga 10× el resto | Escala el conjunto | Escala esa pieza |
| Varios equipos autónomos de producto | Cuellos de merge | Límites claros |
| Operativa 24/7 con on-call real | Un sistema que mirar | Solo si hay plataforma |
| Transacciones entre dominios críticas | ACID en un sitio | Sagas y estados sucios |
El monolito que sí funciona tiene módulos con fronteras. Pedidos no importan usuarios a pelo. El CMS no escribe en la caja. Si mañana quieres extraer pagos, el corte ya está dibujado. Eso se llama monolito modular, no «dejarlo para luego». Es el punto de partida que recomendamos en casi todo proyecto web a medida que no nace con tres squads.
Si estás eligiendo stack y te plantean WordPress porque «es más simple» o Laravel porque «ya es backend de verdad», la conversación de arquitectura va después del CMS, no antes. El artículo de Laravel vs WordPress cubre esa capa. Aquí hablamos de cómo se parte lo que construyas encima.
Cuándo sí conviene trocear
Conviene cuando un límite de negocio ya es estable y duele. El motor de precios tarda 800 ms y tumba el TTFB de la ficha. El generador de PDFs come CPU y no puede compartir máquina con el checkout. El equipo de datos quiere desplegar cada día y el de contenidos, cada mes. Ahí un servicio —o un worker con cola— no es postureo. Es aislar un fallo y un ritmo.
Conviene cuando hay equipos que no pueden esperar al mismo release train. No «somos cuatro y queremos autonomía». Autonomía de verdad: backlog propio, SLA propio, staging propio. Si el mismo senior revisa todos los PRs, los microservicios no te dan independencia. Te dan más repositorios para el mismo cuello.
Extraer un servicio no es el primer movimiento. Primero: módulo, cola, proceso aparte, caché, índices. Si con eso el dolor baja, te ahorras años de Kubernetes. La arquitectura headless a veces se vende como el mismo salto («separamos front y back y ya somos modernos»). Separar el front no te obliga a trocear el back. Son decisiones distintas.
La factura operativa que casi nadie presupuesta
Cada servicio nuevo no es solo código. Es CI, secretos, observabilidad, runbooks, backups, rotación de claves, entornos. En un monolito eso existe una vez. En cinco servicios, cinco veces —o un equipo de plataforma que lo unifique. Si no tienes ese equipo, el senior que «quería microservicios» acaba de convertirse en SRE a tiempo parcial.
Depurar un pago fallido en un monolito: logs, request id, transacción. En microservicios: correlation id, tracing, tres timeouts distintos y un mensaje que se procesó dos veces. Sin OpenTelemetry y sin disciplina de logs estructurados, no tienes arquitectura distribuida. Tienes un sistema que miente cuando falla.
¿Quién se levanta a las 3:00 si el servicio de stock deja de responder y el checkout sigue vivo? Si la respuesta es «nadie, o yo entre cliente y cliente», todavía no estás listo para trocear.
Tip técnico: extrae por dolor medido, no por carpeta
Una regla que usamos: no extraigas un servicio hasta que el módulo tenga frontera estable, tests de contrato y un motivo cuantificado (latencia p95, CPU, frecuencia de deploy, o incidentes). El corte se hace por caso de uso —«reservar butaca», «emitir factura»—, no por capa («todo el repositorio de usuarios»). Si dos servicios necesitan la misma transacción, todavía son el mismo servicio. Y si vas a compartir la misma tabla, no has extraído nada: has creado dos dueños de un dato. Eso es deuda técnica con latencia de red.
Cómo decidimos en Truman, sin dogma
Empezamos por el producto. Qué tiene que pasar en el primer año, quién lo opera, qué integraciones hay. Luego dibujamos módulos. Si el cliente llega pidiendo microservicios porque «así escalamos», preguntamos a qué número. Diez mil usuarios concurrentes no es el mismo problema que cien pedidos al día. Mentir sobre el tráfico es caro: o te sobra infra, o te falta arquitectura el día que de verdad creces.
En plataformas con lógica propia —Klapper es el ejemplo interno más claro— priorizamos un backend coherente, APIs bien versionadas y workers para lo asíncrono. Eso ya te da respiración: generar entradas, emails, conciliaciones, sin bloquear la request del usuario. No es microservicios. Es un monolito que no hace todo en el request HTTP.
Cuando un cliente industrial o un grupo con varios negocios —el tipo de complejidad que vimos en EIM Jeanología— necesita webs, contenidos e integraciones, la conversación suele ser de CMS, permisos y rendimiento, no de orquestación de veinte pods. El criterio es el mismo: no pagues distribución hasta que la unidad te quede pequeña.
Los microservicios no son un premio por haber crecido. Son el precio que pagas cuando un solo proceso y un solo equipo ya no dan abasto. Si todavía te dan abasto, cobra el premio: un sistema que puedes entender un martes por la tarde.
Antes de trocear el sistema, verifica esto
- ¿Tienes un módulo con latencia, CPU o frecuencia de deploy claramente distinta al resto?
- ¿El dominio de esa pieza lleva al menos un ciclo estable, no dos sprints de hipótesis?
- ¿Puedes definir el contrato (API + eventos) sin compartir tablas?
- ¿Hay un dueño de operativa —alertas, on-call, runbook— para el servicio nuevo?
- ¿El equipo supera el tamaño en el que un único repo ya genera colas de merge reales?
- ¿Has agotado módulo + cola + proceso aparte antes de abrir otro repositorio?
- ¿Una transacción de negocio puede vivir dentro del nuevo límite, sin saga improvisada?
- ¿El presupuesto incluye observabilidad, no solo horas de desarrollo?
Preguntas frecuentes sobre monolito vs microservicios
¿Cuál es la diferencia entre monolito y microservicios?
El monolito se despliega como una unidad y comparte proceso y, casi siempre, base de datos. Los microservicios se despliegan por separado, se hablan por red y cada uno es dueño de su dato. La diferencia no es el número de carpetas. Es el número de fallos de red y de releases independientes que estás dispuesto a operar.
¿Cuándo pasar de monolito a microservicios?
Cuando un límite de negocio ya es estable y duele: escala distinta, radio de explosión inaceptable, o equipos que no pueden compartir el mismo tren de release. No cuando el producto aún cambia de forma cada mes. Extrae una pieza, no «migra a microservicios» como proyecto abstracto.
¿Un monolito modular es lo mismo que microservicios?
No. El monolito modular tiene fronteras en código y, si hace falta, en procesos o colas. Sigue siendo un despliegue y un modelo de datos coherente. Los microservicios añaden independencia de release y de fallo a costa de consistencia y operativa. El modular es el paso intermedio que casi siempre falta.
¿Los microservicios son más escalables que un monolito?
Escalan de forma más granular: puedes dar más máquina a un servicio y no a todo. Un monolito bien cacheado, con workers y una base cuidada, escala en vertical y en réplicas más de lo que admite la mayoría de negocios. Si tu cuello es la base compartida, trocear servicios que siguen leyendo la misma tabla no escala: reparte el mismo problema.
