Microservicios: ¿cuándo tienen sentido realmente?

El término microservicios se repite tanto en reuniones de arquitectura que ya casi ha perdido significado. Muchos equipos los adoptan porque “es lo que hacen las empresas grandes” — y eso suele ser el primer error.

El monolito no es el enemigo

Antes de dividir cualquier cosa, hay que entender qué problema estás intentando resolver. Un monolito bien estructurado puede llevar a una startup de cero a millones de usuarios sin problema. Netflix, Amazon y Uber empezaron como monolitos. Los distribuyeron porque tenían problemas de escala muy específicos — no porque el monolito fuera malo.

Un monolito modular (también llamado modulith) te da:

• Deployment simple: un artefacto, una pipeline, un ambiente.
• Debugging directo: stack traces completos, sin saltar entre servicios.
• Transacciones fáciles: todo en la misma base de datos.
• Velocidad de desarrollo: sin la fricción de APIs entre servicios.

¿Cuándo sí tienen sentido los microservicios?

Existen señales claras de que llegó el momento de distribuir:

1. Diferentes cadencias de despliegue

Si el equipo de pagos necesita desplegar 10 veces al día y el equipo de reportes una vez a la semana, un monolito los frena mutuamente. Separar les da autonomía real.

2. Equipos que se bloquean entre sí

Cuando dos equipos modifican constantemente los mismos archivos y sus merges se vuelven un caos, esa fricción es una señal de que los límites del dominio no están bien definidos y que un servicio independiente daría más velocidad.

3. Requerimientos de escala muy distintos

Si tu módulo de búsqueda necesita 20 instancias pero el módulo de facturación solo necesita 2, escalar el monolito entero es costoso e ineficiente.

4. Tecnologías incompatibles

A veces necesitas Python para ML y Go para un servicio de alta performance. En ese caso, la separación técnica tiene justificación real.

El error más común

Adoptar microservicios antes de entender los límites del dominio es el error más costoso. Si no sabes dónde termina un servicio y empieza otro, vas a construir un sistema distribuido con todos los problemas de la distribución y ninguno de sus beneficios — lo que Martin Fowler llama un distributed monolith.

# Anti-patrón: microservicios acoplados
UserService → llama → OrderService → llama → ProductService → llama → UserService

Esto no es distribución; es un monolito con latencia de red.

Patrón recomendado

Si estás empezando, construye un monolito modular con interfaces claras entre módulos. Cuando tengas evidencia (métricas, problemas reales de equipo, necesidades de escala), extrae el módulo que más lo necesite como un servicio independiente.

src/
  modules/
    users/
      UserService.ts
      UserRepository.ts
    orders/
      OrderService.ts
      OrderRepository.ts

Este código está listo para extraerse como microservicio cuando lo necesites, sin reescribir la lógica.

Conclusión

Los microservicios no son una meta en sí mismos — son una herramienta para problemas específicos de organización y escala. Úsalos cuando el costo de no tenerlos supere el costo de la complejidad operativa que introducen. Hasta entonces, un buen monolito es tu mejor amigo.

Si tienes dudas sobre la arquitectura correcta para tu sistema, conversemos — es lo que hacemos.