Hay un momento en la carrera de todo ingeniero en que los microservicios parecen la respuesta a todo. El mío fue hace unos seis años.
Cada proyecto nuevo, cada producto desde cero, el mismo libreto: servicios separados, colas de mensajes, API gateways.
Se sentía como hacer las cosas “bien”.
Me costó sacar unos cuantos productos para admitir algo incómodo:
Estaba optimizando para escala antes de tener algo que valiera la pena escalar.
La tentación de “hacerlo bien”
Si has trabajado en sistemas a escala, los microservicios tienen sentido intuitivo.
Ya viste:
- monolitos que se volvieron inmanejables
- cuellos de botella de deploy entre equipos
- una falla que tumba todo en cascada
Entonces, cuando arrancás algo nuevo, el instinto es:
“No repitamos esos errores.”
Separás todo desde temprano:
- servicio de auth
- servicio de notificaciones
- servicio de facturación
Cada uno con su repo, su pipeline de deploy y su base de datos.
En papel se ve limpio.
En la realidad, acabás de multiplicar la complejidad de un producto con cero usuarios.
Lo que pasa el día cero
Un patrón que he visto una y otra vez cuando un equipo arranca con microservicios:
Semanas 1–2 No estás construyendo producto. Estás construyendo infraestructura:
- setups de Docker
- service discovery
- comunicación entre servicios
Estás resolviendo problemas de sistemas distribuidos antes de validar el feature principal.
Semanas 3–4 Un cambio simple se vuelve coordinación:
- varios servicios
- APIs versionadas
- consistencia de datos entre servicios
Lo que debió ser una migración ahora es un problema de diseño de sistemas.
Semanas 5–8 Te das cuenta de que:
- tu “servicio de notificaciones” casi no hace nada
- tu “servicio de auth” es una capa delgada sobre JWT
Construiste para una escala que no tenés, y que probablemente nunca vas a tener.
Mientras tanto, alguien más sacó un monolito en dos semanas y ya está hablando con usuarios.
El monolito que funciona
Los últimos productos que he construido arrancaron como monolitos modulares.
No código espagueti. No una gran bola de lodo.
Un sistema con fronteras internas claras, sin la complejidad de lo distribuido.
src/
modules/
auth/
flags/
billing/Cada módulo:
- es dueño de su dominio
- expone interfaces explícitas
- se mantiene aislado por dentro
Pero todo:
- se despliega junto
- comparte una base de datos
- se comunica con llamadas a funciones, no por HTTP
El resultado: menos piezas en movimiento y un código que de verdad puedo razonar.
No necesitás sistemas distribuidos para tener buena arquitectura.
Dónde fallan los monolitos modulares
Un monolito no se mantiene limpio solo.
Los he visto venirse abajo cuando:
- los módulos empiezan a meterse en las entrañas de otros
- la base de datos se vuelve un botadero compartido
- los “arreglos rápidos” se saltan las fronteras
En ese punto, el problema no es la arquitectura. Es la disciplina.
Un monolito malo duele. Un sistema de microservicios prematuro duele más, y encima con pipelines extra que mantener mientras tanto.
Cuándo sí tienen sentido los microservicios
Los microservicios no están mal. Muchas veces solo llegan antes de tiempo.
Empiezan a tener sentido cuando:
- Tenés varios equipos que necesitan ciclos de deploy independientes
- Una parte específica del sistema tiene necesidades de escala distintas
- Observaste fronteras reales con el tiempo, en vez de imaginarlas de entrada
Fijate en lo que falta:
- “buenas prácticas”
- “escalar en el futuro”
- “así lo hacen las empresas grandes”
El impuesto escondido de los microservicios
Cada servicio suma costo:
- pipelines de deploy que mantener
- monitoreo y alertas que configurar
- fallas de red (timeouts, reintentos, circuit breakers)
- retos de consistencia de datos
- complejidad del desarrollo local
- carga cognitiva para cada ingeniero
Para un equipo chico, eso es un impuesto directo a la velocidad.
Y en etapas tempranas, la velocidad es la única ventaja que tenés.
La regla que sigo ahora
No diseñés para escala. Diseñá para el cambio.
Los problemas de escala son raros. Los problemas de cambio son constantes.
Un monolito modular optimiza para el cambio. Los microservicios optimizan para la escala. La mayoría de productos en etapa temprana necesita lo primero.
Mi marco de decisión
Cuando arranco un producto:
- De 0 a la primera tracción → monolito modular
- Varios equipos / dolor de coordinación → evaluar separar
- Cuello de botella de escala claro → extraer solo esa parte
Todo lo demás es optimización prematura.
Lo que optimizo ahora
Mi setup por defecto:
- Monolito modular con fronteras claras
- Una sola base de datos PostgreSQL
- Interfaces internas fuertes entre módulos
- Extraer solo cuando el dolor es real
Porque me deja sacar rápido, cambiar de rumbo sin un plan de migración y aprender de usuarios reales.
Y eso es lo que importa al principio.
Prefiero un monolito sólido con usuarios reales que un setup perfecto de microservicios sin ninguno.