Monolito o microservicios: el umbral está en el equipo, no en el tráfico
La decisión entre un monolito y una arquitectura de servicios la determina cuánta gente va a tocar el código a la vez. El tráfico que esperas apenas cuenta. Si no tienes al menos un equipo con capacidad de desplegar por su cuenta detrás de cada servicio, partir el sistema te añade todos los costes de la distribución y ninguno de sus beneficios.
Qué resuelve cada uno de verdad
Conviene separar lo que cada arquitectura resuelve de lo que se le atribuye.
Un monolito resuelve la coherencia. Una transacción abarca todo lo que necesita, una consulta cruza las tablas que hagan falta, un cambio se despliega entero y o entra todo o no entra nada. Depurar es leer una traza. Probar en local es arrancar una cosa.
Los microservicios resuelven la autonomía organizativa. Cada equipo despliega cuando quiere, elige sus tiempos y no espera a nadie. Ese es el beneficio principal y es un beneficio de coordinación humana.
Lo que se les atribuye y no es cierto de forma automática:
- Que escalan mejor. Un monolito escala horizontalmente igual de bien mientras la base de datos aguante, que es donde está el límite real en la mayoría de los productos.
- Que aíslan fallos. Solo si has diseñado la degradación. Sin cortacircuitos ni tiempos de espera, un servicio lento tumba a todos los que dependen de él y encima de forma más confusa que un monolito caído.
- Que permiten usar el lenguaje adecuado para cada cosa. Cierto, pero suele acabar siendo cuatro lenguajes que nadie del equipo domina a la vez.
Los criterios que sí deciden
| Criterio | Favorece monolito | Favorece servicios |
|---|---|---|
| Equipos que despliegan | Uno | Tres o más, con autonomía real |
| Ritmo de despliegue | El mismo para todo | Muy distinto por área |
| Perfil de carga | Homogéneo | Una parte consume mucho más que el resto |
| Requisitos de cumplimiento | Comunes | Una parte tiene requisitos aparte |
| Dependencia entre datos | Alta, todo se consulta con todo | Baja, fronteras claras |
| Madurez de operación | Normal | Alta: trazas, despliegues, guardia |
El primero es el que manda. Los demás matizan.
El criterio que compara todo el mundo y da igual
El número de usuarios. Aparece en la primera línea de casi todas las discusiones y no decide nada por sí solo.
Un producto con cien mil usuarios y un patrón de uso homogéneo funciona perfectamente como monolito. Un producto con doscientos usuarios donde una función concreta procesa ficheros pesados puede necesitar sacar esa función fuera desde el principio. Lo que decide es la forma de la carga y quién la toca. El volumen, por sí solo, dice poco.
El segundo criterio inútil: qué usan las empresas grandes. Las arquitecturas de las compañías con cientos de ingenieros resuelven un problema de coordinación entre cientos de ingenieros. Copiarlas con cuatro personas importa la solución sin importar el problema.
El umbral
Aquí está la respuesta concreta, que es lo que casi nadie da:
Un servicio se separa cuando hay un equipo capaz de mantenerlo, desplegarlo y responder de él por su cuenta. Sin ese equipo detrás, es solo una parte de tu monolito que ahora falla por la red.
Traducido a números, para un producto que se está construyendo:
- Menos de 8 personas de desarrollo: monolito modular. Nimboo no conoce excepciones.
- De 8 a 25: monolito modular con fronteras internas muy marcadas y como mucho uno o dos servicios sacados fuera por un motivo concreto y nombrable.
- Más de 25 en varios equipos: la conversación empieza a tener sentido y aun así se hace por partes y con un motivo por cada parte.
Y una regla que no depende del tamaño: el número de servicios no debería superar al número de equipos. Doce servicios y dos personas dan doce sitios donde buscar el mismo error.
Lo que se paga al partir
Estas son las facturas que no aparecen en las presentaciones. Todas son reales y todas llegan.
- Las transacciones desaparecen. Lo que era una operación atómica pasa a ser una coreografía con compensaciones. Es la factura más cara y la que más se subestima.
- Las consultas que cruzaban tablas ya no existen. O duplicas datos, o haces varias llamadas y compones en memoria. Las dos opciones tienen mantenimiento.
- Cada llamada puede fallar. Necesitas tiempos de espera, reintentos, idempotencia y cortacircuitos en cada frontera. Son código que hay que escribir y probar.
- Depurar cambia de naturaleza. Sin trazas distribuidas ya montadas, encontrar dónde se van los milisegundos pasa de mirar una traza a reconstruir una historia entre siete registros.
- El entorno local se complica. Arrancar el producto entero deja de ser trivial y el coste se paga cada mañana, por persona.
- Los despliegues se ordenan. Dos servicios que cambian a la vez tienen un orden correcto y descubrirlo en producción es caro.
Ninguna es un argumento definitivo en contra. Todas juntas son el motivo de que un equipo de cuatro personas que parte su sistema en ocho servicios vaya más lento seis meses después.
El monolito modular, que es lo que gana casi siempre
La opción que casi nunca se nombra en la discusión y que es la respuesta correcta la mayoría de las veces.
Un monolito modular es un solo desplegable con fronteras internas de verdad: módulos que se comunican por interfaces explícitas, que no leen las tablas de otro módulo y que podrían separarse si algún día hiciera falta.
Lo que da:
- Coherencia transaccional y consultas normales, que es lo bueno del monolito.
- Fronteras claras, que es lo bueno de los servicios.
- La opción de separar más adelante con la información que hoy no tienes: cuál es la parte que de verdad necesita ir aparte.
Un desplegable, seis fronteras. Si algún día hay que separar un módulo, ya se sabe por dónde corta.
Lo que exige no es poco: disciplina. Sin nada que impida a un módulo leer la tabla de otro, las fronteras se erosionan en meses. Conviene que la propia estructura del proyecto lo dificulte y que la revisión de código lo mire de forma explícita.
Cuándo esto no aplica
Dos casos en los que la recomendación se invierte.
Si una parte del sistema tiene un perfil de recursos radicalmente distinto —procesar vídeo, generar informes muy pesados, ejecutar modelos— sacarla fuera desde el principio es correcto aunque seas una persona. Eso es un trabajador aparte, algo normal desde hace décadas. Nadie lo llamaría arquitectura de microservicios.
Si una parte tiene requisitos de cumplimiento propios —datos de salud, datos de pago que no quieres que toquen tu sistema principal— separarla reduce el alcance de lo que hay que auditar y eso vale dinero real.
Fuera de esos dos casos, la pregunta útil es «¿cuántas personas van a desplegar esto de forma independiente el año que viene?». Si la respuesta es una o dos, la arquitectura ya está decidida.
Nimboo construye producto entero y la decisión de arquitectura se toma en la fase de diseño, antes de escribir código, con el alcance ya cerrado. Cómo funciona esa fase está en SaaS a medida y Vecinly es un producto en producción construido con este criterio.