La promesa de los microservicios
Entre 2015 y 2020, la industria se convenció de que los microservicios eran la respuesta a todo. Netflix los usaba. Amazon los usaba. Si no separabas tu app en 20 servicios independientes, estabas haciendo algo mal.
La promesa era clara: equipos independientes, deploys independientes, escalamiento independiente, tecnología independiente por servicio. Suena perfecto en la charla de conferencia.
En la práctica, para la mayoría de los equipos que no son Netflix, significó otra cosa.
Lo que nos pasó
Teníamos un monolito en Laravel que funcionaba. Manejaba usuarios, pagos, notificaciones, reportes. Un solo repo, un solo deploy, un solo servidor. El equipo tenía 4 personas.
Decidimos “modernizar” y separar en microservicios. Usuarios en un servicio, pagos en otro, notificaciones en otro. Cada uno con su base de datos, su API, su deploy.
Resultado después de 6 meses:
- 3 servicios en lugar de 1 app.
- 3 pipelines de CI/CD que mantener.
- Comunicación entre servicios con colas de mensajes que a veces perdían eventos.
- Debugging distribuido — un bug que antes era un stack trace ahora requería correlacionar logs de 3 servicios.
- El mismo equipo de 4 personas intentando mantener todo.
No ganamos velocidad. Ganamos complejidad.
Por qué el monolito funciona para la mayoría
Un monolito bien estructurado no es una bola de barro. Es una app con módulos claros, separación de responsabilidades y tests. La diferencia con microservicios es que la comunicación entre módulos es una llamada de función, no un request HTTP.
# Monolito modular
app/
├── modules/
│ ├── auth/ # Autenticación
│ ├── billing/ # Pagos
│ ├── notifications/ # Notificaciones
│ └── reports/ # Reportes
├── shared/ # Código compartido
└── tests/Cada módulo tiene su dominio, sus tests, su lógica. Pero comparten la misma base de datos, el mismo deploy, el mismo proceso. Sin network calls innecesarios, sin problemas de consistencia eventual, sin colas de mensajes para operaciones síncronas.
Cuándo los microservicios sí tienen sentido
No estamos diciendo que los microservicios son malos. Tienen sentido cuando:
- Equipos grandes (20+ developers) donde cada equipo necesita autonomía real.
- Escala diferenciada — un servicio recibe 100x más tráfico que otro y necesita escalar por separado.
- Tecnologías diferentes — un servicio necesita Python para ML y otro necesita Go para alto rendimiento.
- Dominios realmente independientes — si un servicio puede funcionar sin los otros, probablemente merece ser independiente.
Para un equipo de 3-10 personas con una app web estándar? Monolito modular. Sin dudas.
El modelo que nos funciona hoy
Usamos lo que algunos llaman “monolito modular” o “modular monolith”:
- Un solo repo, un solo deploy — simplicidad operacional.
- Módulos con boundaries claros — cada módulo expone una interfaz pública y esconde su implementación.
- Base de datos compartida pero con schemas separados — cada módulo es dueño de sus tablas.
- Tests por módulo — cada módulo tiene sus propios tests unitarios y de integración.
Si algún día necesitamos extraer un módulo a un servicio independiente, la separación ya está hecha. Pero no pagamos el costo operacional hasta que sea necesario.
La lección
La arquitectura correcta depende del problema, no de la tendencia. Microservicios resuelven problemas de escala organizacional. Si tu problema no es escala organizacional, la solución probablemente tampoco lo sea.
Empieza con el monolito. Estructura bien. Extrae servicios cuando el dolor justifique la complejidad. No antes.
