"Microservicios" suena a arquitectura moderna, y "monolito" suena a legado. En la práctica, la mayoría de startups estarían mejor con un monolito bien construido, y muchas de las que se lanzan a microservicios demasiado pronto acaban pagando un precio operacional que no anticiparon.
El monolito, infravalorado
A favor: un solo codebase, un solo deploy, una sola base de datos. El debugging es directo —un stack trace apunta a la línea exacta del problema, sin tener que perseguir logs distribuidos entre servicios. No hay latencia de red entre módulos porque todo vive en el mismo proceso. Los tests end-to-end son mucho más simples de escribir. Y las transacciones ACID entre entidades relacionadas simplemente funcionan, sin tener que lidiar con consistencia eventual.
En contra: si una feature está lista y otra no, normalmente hay que esperar o desplegar igual. Todo el equipo comparte el mismo stack tecnológico, así que no hay margen para que un equipo use Rust y otro Python. Y a partir de cierto tamaño (varios cientos de miles de líneas en un solo repo), la navegación por el código empieza a ser incómoda.
Es la opción óptima cuando el equipo de backend tiene menos de veinte personas, la app no es descomunal, ninguna feature necesita escalar de forma independiente del resto, y la consistencia de datos importa (finanzas, transacciones).
Microservicios: complejidad real a cambio de beneficios reales
A favor: cada servicio se despliega de forma independiente, lo que puede acelerar mucho la velocidad de entrega. Cada equipo puede elegir su stack tecnológico. Cada servicio escala por separado según su propia carga. Y equipos pequeños pueden ser dueños completos de un servicio autocontenido.
En contra, y esto hay que tomárselo en serio: diez microservicios significan diez veces los logs, despliegues, monitoring y alertas que gestionar. Cada llamada entre servicios añade latencia de red, con el riesgo de fallos en cascada. Las transacciones distribuidas son genuinamente difíciles —sagas, event sourcing, consistencia eventual— y un stack trace que cruza cinco servicios es casi imposible de seguir sin tracing distribuido bien implementado. Todo esto normalmente exige un rol de DevOps dedicado a tiempo completo.
La regla general es que los microservicios multiplican el overhead operacional varias veces respecto a un monolito equivalente. Hace falta un motivo de peso —no solo "es lo moderno"— para justificar ese coste.
Cómo decidir
- ¿Cuántos ingenieros de backend? Menos de diez: monolito, sin discusión. Entre diez y veinte: monolito con quizá uno o dos microservicios críticos. Más de veinte: microservicios empiezan a ser viables.
- ¿La app es enorme? Si no, monolito por defecto.
- ¿Alguna feature necesita desplegarse de forma completamente independiente? Si sí, ahí microservicios tienen sentido.
- ¿La consistencia es crítica? Si sí, monolito (transacciones ACID).
Ante la duda, monolito.
Cómo escalar un monolito sin romperlo
El mito es que un monolito no escala. La realidad es que empresas con volúmenes de tráfico muy altos siguen operando sobre arquitecturas mayormente monolíticas, con disciplina de ingeniería en vez de complejidad distribuida. Las estrategias que de verdad ayudan, en orden de cuándo aplicarlas:
1. Sharding de base de datos antes de plantearte separar servicios — partir por user_id en varias bases de datos escala de forma lineal sin introducir la complejidad de microservicios.
2. Caché con Redis:
@cached(redis, ttl=300)
def get_user(user_id):
return db.query(User).filter(id=user_id).first()Reduce la carga sobre la base de datos de forma notable con muy poco esfuerzo de implementación.
3. Trabajos en segundo plano (Celery + RabbitMQ) para no bloquear el request principal con cómputo pesado:
# El request responde de inmediato
send_email.delay(user_id=123) # se ejecuta en un worker aparte4. Extracción selectiva de servicios: mantener el núcleo como monolito (API, usuarios, pedidos) y extraer solo las piezas que de verdad lo necesitan —pagos, por su criticidad; analítica, por su volumen de escritura. Esto da la mayor parte del beneficio de los microservicios con una fracción de su complejidad.
Un camino de crecimiento razonable
Para una startup que escala, un recorrido típico y sensato es: empezar en monolito con velocidad completa; a medida que crece, separar analítica como servicio propio (por su volumen de escrituras); más adelante, si hace falta, separar pagos por su criticidad; y solo evaluar una migración completa a microservicios si el equipo supera los veinte ingenieros y hay un cuello de botella de escalado real y medible, no solo una sensación.
Herramientas
Para monolito: Docker para contenerizar, Docker Compose para desarrollo local.
Para microservicios: Kubernetes para orquestación, Prometheus para monitoring, Jaeger para tracing distribuido, Kong u otro API gateway.
En resumen
El error que se repite es: equipo de tres personas decide hacer microservicios porque suena moderno, y termina con dos personas depurando tracing distribuido y solo una construyendo features. La velocidad cae en picado. Empieza simple, con un monolito. Cuando el tráfico y el tamaño del equipo lo justifiquen de verdad, evalúa dividir. La mayoría de proyectos nunca llega a necesitarlo.
Fuentes:
Comentarios (0)
Deja un comentario
No hay comentarios aún. ¡Sé el primero en comentar!