La trampa del hype arquitectónico
Si hay una decisión que he visto destruir más proyectos que cualquier otra, es elegir microservicios cuando un monolito habría sido perfecto. Y no es culpa de los equipos — la industria lleva años vendiendo microservicios como la solución universal.
No lo son. Son una herramienta más, y como toda herramienta, tienen un contexto donde brillan y otro donde destruyen.
Cuándo el monolito gana
Un monolito bien diseñado es la elección correcta cuando:
- El equipo es pequeño (menos de 10 desarrolladores). La coordinación entre servicios tiene un costo operacional enorme.
- El dominio no está claro. Si no puedes definir boundaries claros entre servicios, vas a terminar con un monolito distribuido — lo peor de ambos mundos.
- Estás en fase de producto temprana. Necesitas iterar rápido, cambiar modelos de datos, pivotar. Un monolito te da esa agilidad.
- No tienes infraestructura DevOps madura. Microservicios requieren CI/CD robusto, orquestación de contenedores, service mesh, monitoreo distribuido...
Cuándo los microservicios justifican su costo
Los microservicios son la elección correcta cuando:
- Equipos grandes e independientes necesitan desplegar sin coordinarse. Netflix, Amazon, Google — tienen miles de ingenieros.
- Escala diferencial: una parte del sistema recibe 100x más tráfico que el resto.
- Tecnología heterogénea: diferentes partes del sistema se benefician de stacks distintos (Python para ML, Go para APIs de alto rendimiento, Node.js para real-time).
- Requisitos de disponibilidad extremos: si el módulo de pagos falla, el catálogo debe seguir funcionando.
El patrón que realmente funciona: el monolito modular
En mi experiencia, el patrón más exitoso para la mayoría de startups y empresas medianas es el monolito modular. Es un monolito, pero con boundaries internos bien definidos:
- Módulos con interfaces públicas claras
- Comunicación entre módulos via interfaces, no acceso directo a tablas ajenas
- Cada módulo puede extraerse a un servicio independiente cuando (y solo cuando) se justifique
Django lo hace naturalmente con su sistema de apps. Next.js con su estructura de módulos. La clave es diseñar para separación, pero desplegar como una unidad.
El costo oculto
Lo que nadie te dice sobre microservicios: debugging distribuido es un orden de magnitud más difícil. Un request que atraviesa 5 servicios puede fallar en cualquiera de ellos, y rastrear el error requiere herramientas de tracing que tienen su propia complejidad.
Mi consejo después de 20 años: empieza con un monolito modular. Mide. Identifica cuellos de botella reales. Extrae solo lo que necesita escalar independientemente. Y nunca, nunca elijas microservicios porque está de moda.