Monolito o microservicios: cómo elegir sin arrepentirse
Publicado el 2026-09-12 por frfrand
Cinco preguntas que deciden mejor que cualquier diagrama, por qué la arquitectura correcta depende de tu equipo y no de tu tecnología, y cómo dejar la puerta abierta a cambiar.
La discusión sobre arquitectura suele empezar por la tecnología y terminar mal. Se elige lo que está de moda, o lo que usa una empresa que tiene mil ingenieros, y después se pelea con las consecuencias durante años.
Cinco preguntas ordenan mejor la decisión, y ninguna es técnica.
1. ¿Cuántos equipos despliegan?
Es la pregunta más importante, porque el beneficio central de separar servicios es que equipos distintos publiquen sin coordinarse.
Un equipo, un despliegue. No es una regla rígida, es una observación de lo que funciona: el costo de coordinar despliegues sólo existe si hay varios equipos coordinándose.
2. ¿Qué es lento de verdad?
Hay que medirlo, no suponerlo.
La mayoría de las veces, el cuello de botella de una aplicación web es una consulta sin índice, la falta de caché, o una llamada externa lenta. Ninguna de esas tres se arregla separando servicios; de hecho, separar agrega latencia de red encima.
Si nunca mediste, la arquitectura no es tu problema todavía.
3. ¿Quién lo opera a las tres de la mañana?
La complejidad tiene un costo que se paga de guardia.
Diez servicios son diez cosas que pueden fallar, diez conjuntos de logs que correlacionar y diez despliegues que revertir. Si el equipo es chico, ese costo lo paga una persona, y lo paga de noche.
Es una consideración legítima y casi nunca aparece en los diagramas.
4. ¿Hay una parte que escala distinto?
Si el procesamiento de vídeo consume veinte veces más que el resto y crece por separado, hay un argumento real para separarlo.
La palabra clave es medido. "Esto probablemente va a crecer" no alcanza: casi nunca crece como se esperaba.
5. ¿Se puede deshacer?
La mejor arquitectura es la que no te encierra.
Y acá hay una asimetría que conviene conocer: extraer un servicio de un monolito bien modularizado es trabajo; volver a juntar servicios distribuidos es mucho peor.
Por eso, ante la duda, el camino menos arriesgado es empezar junto.
El orden que funciona
Monolito modular primero. Un despliegue, una base, y adentro módulos con fronteras claras: cada uno con su interfaz, sin acceder a las tablas de los otros por atrás.
Esa disciplina interna es lo que hace posible todo lo demás. Un monolito sin fronteras internas sí es un problema, y es lo que le dio mala fama a la palabra.
Medir dónde duele. Con datos, no con intuición.
Extraer un servicio, con una razón concreta. Uno. No el sistema entero.
Lo que casi siempre es la respuesta correcta
Para un equipo de menos de diez personas: monolito modular, desplegado de forma automática, con buenos logs y métricas.
Eso no es conservadurismo: es que el beneficio principal de los microservicios (independencia entre equipos) no existe cuando hay un solo equipo, y los costos existen igual.
En ArduMaker esto se traduce en algo práctico: podés tener un monolito desplegado desde un repositorio, y el día que extraigas un servicio, desplegarlo en el mismo VPS o en otro, con túneles entre ellos en vez de exponerlos. La arquitectura puede evolucionar sin rehacer la infraestructura.
