Si abrís cualquier blog de ingeniería de una empresa grande hoy, vas a encontrar artículos sobre cómo migraron de un monolito a microservicios. Son artículos bien escritos, con diagramas impresionantes, y casi siempre concluyen que el cambio fue una decisión excelente.
Lo que esos artículos no cuentan es que esas empresas tienen equipos de 50+ ingenieros, herramientas de observabilidad sofisticadas, años de inversión en infraestructura, y muchas veces el problema que estaban resolviendo era de escala que la mayoría de nosotros nunca va a tener.
El problema con copiar lo que hacen los grandes
Netflix tiene microservicios porque tienen cientos de equipos que necesitan desplegarse de forma independiente, escalar componentes específicos a millones de usuarios, y no bloquearse mutuamente. Eso tiene sentido para Netflix.
Pero vos no sos Netflix. Y yo tampoco.
Cuando una startup de 10 personas decide hacer microservicios desde el día uno “porque así escala mejor”, generalmente está tomando una de las decisiones más caras que puede tomar.
¿Por qué? Porque los microservicios tienen un costo fijo muy alto:
- Latencia de red: cada llamada entre servicios es una llamada HTTP o gRPC que puede fallar, que agrega latencia, que necesita retry logic y circuit breakers.
- Consistencia de datos: ya no podés hacer una transacción de base de datos que abarque múltiples servicios. Cada operación distribuida necesita ser diseñada con cuidado.
- Observabilidad: debuggear un error que atraviesa tres servicios es exponencialmente más difícil que debuggear uno en un monolito.
- Deployments: coordinar el deploy de múltiples servicios con dependencias entre ellos es complejo.
- Infraestructura: cada servicio necesita su propio pipeline de CI/CD, su propia configuración, su propio monitoreo.
Todo ese costo existe desde el primer día. Los beneficios, en cambio, se materializan mucho más tarde.
Cuándo el monolito es la respuesta correcta
La mayoría de las veces. En serio.
Un monolito bien estructurado puede manejar cantidades de tráfico sorprendentes. Stack Overflow corre en un puñado de servidores usando un monolito en C#. Shopify durante años fue un monolito en Rails. Basecamp también.
Lo que hace difícil a un monolito generalmente no es la arquitectura en sí, sino cómo creció: sin límites claros entre módulos, con lógica de negocio mezclada con lógica de presentación, con dependencias circulares entre componentes.
Eso no es un problema de monolitos. Es un problema de disciplina en el diseño.
El monolito modular: el mejor de los dos mundos
Lo que recomendamos en la mayoría de los proyectos que arrancamos es lo que se conoce como monolito modular: una aplicación única, pero con límites claros entre sus componentes internos.
En Django, esto se traduce en apps bien delimitadas, cada una con sus propios modelos, lógica de negocio y tests, comunicándose entre sí a través de interfaces definidas (no importaciones directas entre modelos de distintas apps).
# Bien: comunicación a través de una interfaz definida
from payments.services import create_charge
# Mal: acceso directo a modelos de otro dominio
from payments.models import Transaction
Esta estructura permite:
- Moverse rápido ahora: sin la complejidad operacional de microservicios.
- Extraer servicios después: si en el futuro un módulo necesita escalar de forma independiente, el límite ya está trazado y la extracción es quirúrgica.
El monolito modular es el camino hacia los microservicios, si algún día los necesitás.
Cuándo tiene sentido considerar microservicios
Hay casos donde los microservicios son la respuesta correcta:
Escala organizacional: cuando tenés múltiples equipos que necesitan deploys independientes y no pueden bloquearse entre sí. Si tenés un equipo de 5 personas, esto no aplica.
Escala técnica diferenciada: cuando una parte específica del sistema necesita escalar de forma muy distinta al resto. Por ejemplo, un servicio de procesamiento de imágenes que necesita GPU vs el resto de la API que corre en CPU estándar.
Aislamiento de fallos crítico: cuando la caída de un componente no puede afectar al resto. En sistemas de pagos o salud, esto puede justificar la complejidad adicional.
Tecnología específica por dominio: cuando una parte del sistema se beneficia enormemente de un lenguaje o runtime específico que no tiene sentido para el resto.
La clave es que el problema tiene que existir hoy, no en un futuro hipotético.
La historia que siempre cuento
Heredamos un proyecto hace dos años. Una plataforma SaaS con 8 microservicios, construida por un equipo de 4 personas. Tenía problemas de performance que nadie podía debuggear porque los logs estaban fragmentados entre servicios, sin tracing distribuido. Cada feature nueva tardaba el doble porque tocaba dos o tres servicios. Los deploys eran eventos de alto riesgo.
Lo primero que hicimos fue consolidar los servicios que no tenían razón de ser independientes. Pasamos de 8 a 3. El tiempo de debugging cayó a la mitad. Los deploys dejaron de ser traumáticos.
La plataforma no necesitaba esa complejidad. La habían construido así porque “así se hace ahora”.
La regla simple
Empezá con un monolito bien estructurado. Cuando tengas un problema concreto que el monolito no pueda resolver —y ese problema sea real, no hipotético— extraé el servicio que necesitás.
No al revés.
¿Estás evaluando la arquitectura de tu plataforma? Nos especializamos en estos análisis. Hablemos.